Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-194.txt

Text File | 1994-12-08 | 122.0 KB | 2,632 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 20 Oct 92       Volume 1 : Issue 194

Today's Topics:

    NON-QUICKDRAW GAMES



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Ben Haller)
Subject: NON-QUICKDRAW GAMES
Date: 2 Sep 92 23:53:14 GMT
Organization: Stick Software

<I am crossposting this question, which arose in comp.sys.mac.games,
 to comp.sys.mac.programmer since it seems appropriate.  I don't
 read comp.sys.mac.programmer, so followups that I might want to
 see / reply to, please keep in comp.sys.mac.games as well...>

In article <[e-mail]> [e-mail]
  (JOSTEIN SVENDSEN) writes:
>In article <[e-mail]> [e-mail]
>  (Ben Haller) (me) writes:

>>  The posting you saw was probably mine.  This is correct, many (most?)
>>fast-action games for the Mac do not use QuickDraw.  Certainly I would
>>never even attempt to write a fast-action game using QuickDraw.  The
>>"other method" that is used is to write directly to the memory that
>>represents the screen, with custom assembly code that results in faster
>>drawing than QuickDraw is able to achieve.

>   Can you please give me some hints/tips on how to learn the skills
>neccessary to program fast-action games for the Mac?
>- e.g. books, sources, programming languages etc.

  Well.  This topic has been covered many times on comp.sys.mac.programmer,
and a (partial, at least) answer is in UMPG, the UseNet Macintosh
Programmer's Guide, the ordering details of which can be found in the
c.s.m.p. FAQ file.  But, since I'm in a good mood, I'll go over it briefly.
 Books: UMPG has stuff, as mentioned above.  Inside Macintosh has all the
actual technical details you need (if you include the tech notes, the 32
Bit QuickDraw documentation, etc.), although putting the pieces together
can be difficult, as usual with IM.  The latest (is it still the latest?)
d e v e l o p magazine (available from Apple or APDA somehow, I believe)
has quite a good article on direct to screen video, that's a very good
source.  It has been mentioned in many other places, in varying levels of
detail, but these three sources seem easy to find and relatively helpful.
  Sources.  The only source code I know of that uses direct to screen video
in a significant way is Juri Munki's (sp?) VectorKit code, which is now
publicly available from some FTP site which he just told me, but which I
forgot to save.  Someone else can surely produce the FTP site if there is
demand.  There may be source available for other things that I am not aware
of.  Source to my games (Solarian II, Lunatic Fringe) is not available no
matter how much you beg, so please don't try.
  Programming languages.  Think C is usually best for small projects,
games, trivial things.  MPW C or C++ is better for projects being worked on
by several people.  You may want to still use Think C, but use MPW to
project your source files for version control, etc.
  The actual code is really not very hard.  You get the base address of the
monitor from the GDevice record of the monitor (see IM 5, GDevices), or by
calling GetPixBaseAddr (but beware, old versions of that trap returned 0 in
at least some cases).  You synch to the monitor by installing a VBL task
with SlotVInstall (VInstall only synchs you to the monitor on the
non-color-QuickDraw machines), getting the slot number from the AuxDevRec
or some darn thing, which you get indirectly from the GDevice record (this
is vague, I know, I could dig up details if needed).  You change pixels by
simply writing to the memory off of the base address of the screen (beware,
you may be in 24-bit mode and you may need to be in 32-bit mode, call
SwapMMUMode to switch modes).  You may or may not want to notify the system
that you have changed the pixels (PixMapChanged, or PixelsChanged, or some
such trap - basically makes the GC card slightly less crash-prone than it
otherwise is...)  Don't write outside of the actual screen space, leave the
machine in the memory mode is was in when you're done, etc. and you'll be
fine.  Did I forget anything?
  I'd be glad to help anybody who needs it through e-mail, but remember,
if your question is general at all, others would probably appreciate
seeing the question and answer on the net, so you may want to keep
discussion there.  Please respect the request about continuing the
crossposting to both groups (c.s.m.p. and c.s.m.g.) since I do think it
is relevant to both groups...

- -Ben Haller ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Michael A. Kelly)
Organization: University of Oregon Computer and Information Sciences Dept.
Date: Thu, 3 Sep 1992 00:35:08 GMT


Some sample code for drawing directly to video memory can be found in the
comp.sys.mac.programmer FAQ, which was posted Tuesday to c.s.m.p. and
news.answers.  It implements the basics, but for a real game you'll have
to check into installing a VBL task and notifying the system of changes
(using ShieldCursor, etc.).

So, Juri, where is this VectorKit code Ben mentioned?

Mike.
- --
_____________________________________________________________________________
Michael A. Kelly                                         University of Oregon
[e-mail]                             Computer Science Department
_____________________________________________________________________________

+++++++++++++++++++++++++++

From: [e-mail] (joe holt)
Organization: Adobe Systems Inc.
Date: Thu, 3 Sep 1992 21:28:02 GMT

This is a fun subject, and I'd like to help spread the religion. Let me add
a few bits:

To begin, insert all of the reasons *not* to draw directly to the screen.
Would someone like to enumerate them? My favorite is that this can cause the
GC card to crash. As if it needed my help. :-)

Personally, it bothers me to hear people cry about how dangerous it is to
bypass QuickDraw, as if it's a matter of personal safety (you'll go blind).
Most likely these people have never done it, or at least not to the extent
that you do when really writing a game (or other application--did you know
that ATM draws straight to the screen?). It can be scary as you're learning,
because there are a few gotchas. Having done it, however, you realize that
the entire strategy is easy to understand. All of the techniques are old old
old game programmer tricks--there is nothing proprietary about them. What's
new is the way they're used on the Mac, and especially the way you get around
some of the Mac's video quirks.

It may not be obvious to everyone that the Mac's video screen is memory-
mapped. That means that the pixels on the screen are also memory locations in
RAM. By writing values into this RAM, you're also playing with pixels on the
screen. This memory is real RAM: you can read the values back that you put in,
and the computer can use it just like any other kind of RAM. In fact, you can
even put programs in the video RAM. Of course, the screen would look like
garbage, but what the hey, it'd be fun. (This used to be a copy protection
technique on the Apple II--put code in the text video RAM. As soon as you drop
into the monitor to hack the code, it scrolls off the screen). Actually,
more interesting would be to put a program's variables in video RAM, and
watch the colors change as the program ran. Now there's an INIT waiting to be
written.

Anyway, so the first question is, where in RAM is the screen?

This turns out to be an easy thing to find out, although the method is
different for Color QuickDraw and non-Color QuickDraw machines. So, the very
first thing you need to do is call SysEnvirons() to find out if the machine
has Color QuickDraw:

    SysEnvRec This_mac;

    SysEnvirons( 1, &This_mac );

Now you can get the base address like this:

    Ptr base_address;

    if ( This_mac.hasColorQD ) {
        GDHandle the_monitor;

        the_monitor = GetMainDevice();
        base_address = (**(**the_monitor).gdPMap).baseAddr;
    }
    else base_address = ScrnBase; /* low-memory global long at 0x824 */

A few things to mention right away. The recommended way to get a GDevice's
base address is slightly different under System 7, but the above will work.
Also, this will just give you the base address of the monitor with the menu
bar on it. This will make those lucky few with multiple monitors angry if
their other monitor is the one they want to play the game on. I'm also
glossing over things like #include files and such.

What happens if you actually use this pointer and stick something there? Try
this:

    int i;
    Ptr p;

    for ( p = base_address, i = 50; i; --i )
        *p++ = 0xAA;

    while ( !Button() );    /* wait for mouse click */
    while ( Button() );

Did anything happen? If your monitor is in black and white, you probably got
a line of alternating pixels across the very top line of the menu bar. If your
monitor is in color, that line is shorter and probably made up of colored pixels.
Rerun this at different monitor depths.

Did your Mac crash instead? Oops. Here's the first gotcha: some video cards,
mostly the newer ones with millions of colors, need to be addressed in 32-bit
mode. If you don't switch to 32-bit addressing before reading or writing into
video RAM, you'll either get an ADDRESS ERROR or clobber other parts of memory
with dire results. The reasons are really arcane and I'll be happy to explain
them, but for now this info will just get in the way of the real fun that
we're having (we are having fun, aren't we?). The little loop above would turn
into this:

    int i;
    Ptr p;
    char old_MMUMode;

    if ( This_mac.hasColorQD ) {
        old_MMUMode = true32b;
        SwapMMUMode( &old_MMUMode );
    }

    for ( p = base_addresss, i = 50; i; --i )
        *p++ = 0xAA;

    if ( This_mac.hasColorQD )
        SwapMMUMode( &old_MMUMode );

You see, what you have to do is set the Mac to 32-bit addressing and save the
previous addressing mode, do your screen stuff, then set it back to the
previous state. While in 32-bit addressing mode, you shouldn't make any ROM
calls (mostly) or dereference handles and the like. The rule-of-thumb is to
get back out of 32-bit addressing as soon as you can. Of course, if you have
System 7 and your Mac is already in 32-bit addressing mode, the above code
will work but the SwapMMUMode()'s are unnecessary. Same is true if the video
card doesn't need 32-bit addressing. To do it right, you really should check
all of these things.

You have just drawn directly to the screen. Hurrah!

As Ben mentioned, there are good sources for this kind of thing, although not
everyone gets  d e v e l o p  magazine. If there is sufficient interest, we
should all pitch in and turn this into a real thread. Things to cover include:

  1. setting up a vbl task
  2. uses and abuses of off-screen buffers
  3. clut animation
  4. protecting your screen real estate
  5. masking techniques
  6. assembly language optimizations
  7. <add yours here>

Let's see how far our collective wisdom can take us...

/joe


+++++++++++++++++++++++++++

From: [e-mail] (Kevin R. Walker)
Date: 4 Sep 92 05:16:50 GMT
Organization: Freshman, MCS general, Carnegie Mellon, Pittsburgh, PA

I think that a continuing thread on the non-QD graphics would be great.
(IMHO)

Anyone with knowledge, please contribute what you are willing - and thanks
to joe holt for his help.

Thanks,
Kip
- ----------
Kip Walker

[e-mail]
[e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Matthew Hall)
Date: 6 Sep 92 18:55:23 GMT
Organization: Oberlin College Computer Science


Thank you for the information about drawing directly to the screen-
now the next question.
In 16 or 32 bit color, it's easy to draw the exact colors you want on
screen just by filling in the RGBColors.  However- in 8 or 4 bit mode,
you have to deal with palettes.  First of all, how do you assign a
palette or color table to the screen.  You could just change the
GDevices pmtable, but would that change the devices actual CLUT?  And
if you set the colors by means of a palette, how do you get the
correct indicies to write?  Conceivably, many machines might not be
running the system software to support pmTolerant+pmExplicit, right?
The drawing to screen stuff I can implement - but if someone could
answer how to draw in an indexed color environment, I would really
appreciate it.

Thank you-
- -matt hall

- --


- -------------------------------------------------------------------------------
Matt Hall.    [e-mail]  OR  [e-mail]
              (216)-775-5805 (That's a Cleveland Area code. Lucky Me)

"If a man comes up to you and says:
    'A dog just carried away your ear.'
Do you run after the dog, or search first for your ear?" - Moon over Morocco


+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 7 Sep 92 07:09:36 GMT
Organization: Kalamazoo College

[e-mail] (Matthew Hall) writes:
>
>First of all, how do you assign a
>palette or color table to the screen.  You could just change the
>GDevices pmtable, but would that change the devices actual CLUT?

Hiss, snarl!  This is Wrong with a capital W.  There's an off chance
that it might work, but IM specifically warns you _never_ to directly
change a system GDevice record.

>And
>if you set the colors by means of a palette, how do you get the
>correct indicies to write?  Conceivably, many machines might not be
>running the system software to support pmTolerant+pmExplicit, right?

pmTolerant and pmExplicit usages have been around since Color QuickDraw
was first put into a Mac.  Actually, you'll probably want
pmAnimated+pmExplicit if you ever want to change colors, say for a fade
to black.  But they work on every CQD Mac, and they're as compatible as
you can get.  :-)
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 I suppose ya don't think I was run over by a streetcar!

+++++++++++++++++++++++++++

From: [e-mail] (Daniel Norman Johnson)
Date: 7 Sep 92 13:17:52 GMT
Organization: Rensselaer Polytechnic Institute, Troy, NY.

In article <[e-mail]>, [e-mail] (Jamie R. McCarthy) writes:
[deletia- don't touch that GDevice]
|>
|> >And
|> >if you set the colors by means of a palette, how do you get the
|> >correct indicies to write?  Conceivably, many machines might not be
|> >running the system software to support pmTolerant+pmExplicit, right?
|>
|> pmTolerant and pmExplicit usages have been around since Color QuickDraw
|> was first put into a Mac.  Actually, you'll probably want
|> pmAnimated+pmExplicit if you ever want to change colors, say for a fade
|> to black.  But they work on every CQD Mac, and they're as compatible as
|> you can get.  :-)

Um, I dont quite see why you need to use pmExplicit in either case... wouldn't
just pmAnimated or pmTolerant do the job all by itself? I wont let u change
teh values of white or black, but then I didn't think pmAnimate+pmExplicit
will do that either.. will it?

Or am I missing something important here?
- --
            - Dan Johnson
And God said "Jeeze, this is dull"... and it *WAS* dull. Genesis 0:0

These opinions have had all identifiying marks removed, and are untraceable.
You'll never know whose they are.

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 7 Sep 92 14:35:09 GMT
Organization: Kalamazoo College

[e-mail] writes:
>[e-mail] (Jamie R. McCarthy) writes:
>|> pmTolerant and pmExplicit usages have been around since Color QuickDraw
>|> was first put into a Mac.  Actually, you'll probably want
>|> pmAnimated+pmExplicit if you ever want to change colors, say for a fade
>|> to black.
>
>Um, I dont quite see why you need to use pmExplicit in either case... wouldn't
>just pmAnimated or pmTolerant do the job all by itself?

They will...but you don't know where the color will end up.  If you want
palette entry #17 to be represented by color table entry #17 on the
screen, use pmExplicit.

Otherwise, when you want to write the color represented by palette entry
#17 to the screen, it could be anywhere in the color table, and you'll
have to do nasty stuff like calling PmForeColor(), checking
theCGrafPort.fgColor, and restoring the original foreground color.  Ick.


Anyway, I take back what I said about "since CQD was first put into a
Mac."  Any of the four usages by itself is OK with any Mac;
pmTolerant+pmExplicit and pmAnimated+pmExplicit were apparently added
with 32-bit QD.  Sorry.  I should read my IM V more often before
making blanket statements like that.  (But it's hard because all the
pages in the Palette Manager and Sound Manager chapters have come
free of the binding.)
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 "I may not understand what you say, but I'll defend to your death
  my right to deny it."                 - Albert, from 'Outrageously Pogo'

+++++++++++++++++++++++++++

From: [e-mail] (Matthew T. Russotto)
Date: Mon, 07 Sep 92 16:51:14 GMT
Organization: College of Engineering, University of Maryland, College Park

In article <[e-mail]> [e-mail] (Matthew Hall) writes:
>
>Thank you for the information about drawing directly to the screen-
>now the next question.
>In 16 or 32 bit color, it's easy to draw the exact colors you want on
>screen just by filling in the RGBColors.  However- in 8 or 4 bit mode,
>you have to deal with palettes.  First of all, how do you assign a
>palette or color table to the screen.
Palette:  Use the Palette Manager to assign a palette to your window,
and call ActivatePalette.  Use pmTolerant entries with a tolerance of
$0000.

Color Table:  SetEntries.  This is rather unfriendly to any other
programs, running, and when used in index mode generates ugly
artifacts during the switch, at least on the Apple TFB cards.

>You could just change the
>GDevices pmtable, but would that change the devices actual CLUT?
No, that would just make a mess on your screen.

> And
>if you set the colors by means of a palette, how do you get the
>correct indicies to write?  Conceivably, many machines might not be
>running the system software to support pmTolerant+pmExplicit, right?

You use PMForeColor and PMBackColor.  If you need to draw directly to
the screen for speed or whatever, you can either make your own lookup
table with Color2Index, and use it, use PMTolerant + PMExplicit if it
is supported, or use SetEntries directly (and risk messing up other
programs)
- --
Matthew T. Russotto    [e-mail]    [e-mail]
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)

+++++++++++++++++++++++++++

From: [e-mail] (Matthew T. Russotto)
Date: 7 Sep 92 16:54:28 GMT
Organization: College of Engineering, University of Maryland, College Park

In article <[e-mail]> [e-mail] (Jamie R. McCarthy) writes:
>
>pmTolerant and pmExplicit usages have been around since Color QuickDraw
>was first put into a Mac.  Actually, you'll probably want
>pmAnimated+pmExplicit if you ever want to change colors, say for a fade
>to black.  But they work on every CQD Mac, and they're as compatible as
>you can get.  :-)

Nope.  PMTolerant+PmExplicit (for getting the right colors in the
right place in the color table) was introduced with 32 bit Quickdraw
(version 1.2, I believe)

- --
Matthew T. Russotto    [e-mail]    [e-mail]
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)

+++++++++++++++++++++++++++

From: [e-mail] (Juri Munkki)
Date: 8 Sep 92 17:30:31 GMT
Organization: Helsinki University of Technology

In article <[e-mail]> [e-mail] (Michael A. Kelly) writes:
>So, Juri, where is this VectorKit code Ben mentioned?

Actually, the package that I put on anonymous ftp has the full source
code for the STORM/ARASHI project. It has the sound kit, game code,
some sample programs and the animation kit and documentation for all
of the above. The code still isn't finished, but I have nop plans or
time to do anything with it, so you'll have to do with what's there
right now. Remember to use binary mode for the downloads!

I might have missed a few source files, so let me know if anything is
missing.

The ftp site is ics.uci.edu. Look for arashi.cpt.bin or something like
that in the mac directory tree. My connection to ics.uci.edu is down right
now, so I can't look where it is exactly. As far as I know, the code should
be also soon available somewhere on Applelink. I have no problems with
redistribution, so if want to put it somewhere else, please drop me a note
even though you don't need my permission.

It's very easy to write new vector animation based games with this kit.
You have to have good C programming experience, but assembler is not required.

You need Think C 5.0 or later and Compact Pro to open the archive.

- --
  Juri Munkki                           Windsurf: fast sailing
 [e-mail]                          Macintosh: fast software

+++++++++++++++++++++++++++

From: [e-mail] (Ben Haller)
Date: 8 Sep 1992 22:42:11 GMT
Organization: Stick Software

In article <[e-mail]>
  [e-mail] (Matthew Hall) writes:
>you have to deal with palettes.  First of all, how do you assign a
>palette or color table to the screen.  You could just change the
>GDevices pmtable, but would that change the devices actual CLUT?  And
>if you set the colors by means of a palette, how do you get the
>correct indicies to write?  Conceivably, many machines might not be
>running the system software to support pmTolerant+pmExplicit, right?
>The drawing to screen stuff I can implement - but if someone could
>answer how to draw in an indexed color environment, I would really
>appreciate it.

  As several people have already indicated, the two basic methods
are either using the Palette Wrecker (oh, did I say wrecker?  I meant
manager) or using SetEntries.  The thing I want to address is this,
in my mind unwarranted, bias towards the Palette Wrecker (there, I
mistyped it again!)
  If you use it, in the best of all possible worlds, when your application
get context-switched in your palette will be swapped back in, using the
best possible slots in the CLUT taking into consideration the colors
everybody else is using, etc. etc.  This is hogwash - it never happens.
In my experience using the palette manager means the screen does CLUT
flashes that are even more distracting than they would usually be (i.e.
it will often flash *several times*), you end up with a pretty crappy CLUT
that in no way avoids frequently-used colors, and the other applications
in the system are often permanantly fucked up and don't redraw correctly
from then on.  It just isn't worth it, folks.  Nobody else uses the Palette
Wrecker, and so all of the much-touted benefits simply aren't there (lack
of entry conflicts with other apps, etc.)  And it has a lot of drawbacks,
not the least being that's it's slow, it increases your code size, it
looks worse, and it's (in my opinion) meither as aesthetically pleasing
nor as compatable as just saving & setting the CLUT (or part of the CLUT)
on resume events and restoring the parts you changed on suspend events.
  Also, if you're using direct-to-screen as almost everyone does - in a
pixel-oriented paint program or in a video game - then you'll want the
whole CLUT to yourself, in which case the Palette Wrecker (even if it
worked) provides no benefits and all the drawbacks.
  Get real.  Just because Apple says to use the Palette Wrecker doesn't
mean you have to.  There is nothing wrong with SetEntries - at least
nothing that the Wrecker fixes.  So why bother.
  OK, I'm ready for the flames... :->

- -Ben Haller ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Daniel Norman Johnson)
Date: 8 Sep 92 23:38:45 GMT
Organization: Rensselaer Polytechnic Institute, Troy, NY.

In article <[e-mail]>, [e-mail] (Ben Haller) writes:
|> In article <[e-mail]>
|>   [e-mail] (Matthew Hall) writes:
|> >you have to deal with palettes.  First of all, how do you assign a
|> >palette or color table to the screen.  You could just change the
|> >GDevices pmtable, but would that change the devices actual CLUT?  And
|> >if you set the colors by means of a palette, how do you get the
|> >correct indicies to write?  Conceivably, many machines might not be
|> >running the system software to support pmTolerant+pmExplicit, right?
|> >The drawing to screen stuff I can implement - but if someone could
|> >answer how to draw in an indexed color environment, I would really
|> >appreciate it.
|>
|>   As several people have already indicated, the two basic methods
|> are either using the Palette Wrecker (oh, did I say wrecker?  I meant
|> manager) or using SetEntries.  The thing I want to address is this,
|> in my mind unwarranted, bias towards the Palette Wrecker (there, I
|> mistyped it again!)

Dang.. ya gotta watch them typos, ya know :)

|>   If you use it, in the best of all possible worlds, when your application
|> get context-switched in your palette will be swapped back in, using the
|> best possible slots in the CLUT taking into consideration the colors
|> everybody else is using, etc. etc.  This is hogwash - it never happens.

Granted. The Palette Manager does not care about which slots it
uses. I don't see why you do.. is there some benefit to particular
slots that I am not aware of? Id think that CLUT slot is pretty
much like annother, unless u r XORing things... Of course, u could use
pmExplicit colors to get specific indicies.

|> In my experience using the palette manager means the screen does CLUT
|> flashes that are even more distracting than they would usually be (i.e.
|> it will often flash *several times*),

I have never seen this myself. Can you give an example?
[ie how can I make it happen?]

Also, I presume the technique you propound somehow gets the screen
to redraw, with the new colors. Otherwise, you'd wind up with the
usual my-background-is-in-briliant-yellow-and-turquoise-and-my-finder-
icons-are-indecyperable syndrome. This bothers me much more than the
"flash" the palette manager produces. And things only get weirder, since
thigns that are redraw/exposed get draw right, but everything else
is still mauve or something. yeck. :)

|> you end up with a pretty crappy CLUT
|> that in no way avoids frequently-used colors, and the other applications
|> in the system are often permanantly fucked up and don't redraw correctly
|> from then on.

Can you give examples of when this happens too? It does not
happen to the programs I have written that use palettes. Also,
why dont they have the same prob with direct-clut-changes?

|>  It just isn't worth it, folks.  Nobody else uses the Palette
|> Wrecker, and so all of the much-touted benefits simply aren't there (lack
|> of entry conflicts with other apps, etc.)

Well, the-no-entry-conflicts thing works for apps that dont use ANY
clut or palette mucking.. they are forced to redraw, and do so with
the new colors. This is of course only in my experience, u have
already said yours differs. It also works for other programs
that use the palette manager, and it does no harm for those that
don't, right?

|>  And it has a lot of drawbacks,
|> not the least being that's it's slow,

granted.

|> it increases your code size,

how does it do this? U can have a palette in a pltt resources
and not add ANY code, if u r using GetNewCWindow. You
can grab palettes from resources with very little
code. Even if you are assembling one on-the-fly, it doesn't seem
to me like it takes nearly as much code to allocate, fill in,
assign and activate a palette as it would to write code to make
clut-manipulation work on multiple monitors,  on direct devices,
on b&w machines, etc

By the way, Im talking about the more general case of
drawing-w/-quickdraw-in-a-window, not just the direct screen drawing
stuff and the take-over-teh-screen stuff, since you appear to be saying
"never use teh Palette Wrecker, ever ever ever". I can see (now) why you
would not want to do this if you are not using windows, quickdraw, etc.
It would be most pointless, but slow anyway. :)

|> it
|> looks worse, and it's (in my opinion) meither as aesthetically pleasing
|> nor as compatable as just saving & setting the CLUT (or part of the CLUT)
|> on resume events and restoring the parts you changed on suspend events.

Why do you say this? The palette manager should be able to completely
change the clut to anything u want, 'cept u have to have black and white
in the clut. Is that such a big difference?

Anyway, if u r gonna save and restore the clut, how do u force all other
apps and such to redraw [in teh case where u r not taking over the
whole screen], and of course also force teh desktop to redraw?

Also, why is the Palette Manager less compatible than CLUT stuff?

|>   Also, if you're using direct-to-screen as almost everyone does - in a
|> pixel-oriented paint program or in a video game - then you'll want the
|> whole CLUT to yourself, in which case the Palette Wrecker (even if it
|> worked) provides no benefits and all the drawbacks.

Well, the Palette Manager takes care of multiple-monitor setups for you,
and direct devices. I thot u'd have to special-case for that if
u r using SetEntries. This doesn't matter if you are taking over the
screen, but that drawing program ought to run in a window.

|>   Get real.

C'mon... I wanna get fake! :(

|>  Just because Apple says to use the Palette Wrecker doesn't
|> mean you have to.  There is nothing wrong with SetEntries - at least
|> nothing that the Wrecker fixes.  So why bother.

Well, the Palette Manager takes care of a bunch of details for you,
which I have mentioned, and lets you share palette entries with other
apps if you like (although this doens't work very well, in my option.
Its that annoying restriction on the values tolerances can take.. you
cant have small, non-zero tolerances. bleah) It also (in my experience,
perhaps yours differs again) can allocate "unused" palette entries- IF
other apps are using the palette manager. If they aren't, no harm (that
I know of) done.

|>   OK, I'm ready for the flames... :->

I tried to be reasonable, and not flame. Mostly because
I have the feeling that Im way, way out of my depth
arguing with you. But what the hey. Now pardon me why
I go dig up my asbestos underwear. I have a feeling
my ignorance is about to be rudely exposed. :)

|> -Ben Haller ([e-mail])

- --
            - Dan Johnson
And God said "Jeeze, this is dull"... and it *WAS* dull. Genesis 0:0

These opinions have had all identifiying marks removed, and are untraceable.
You'll never know whose they are.

+++++++++++++++++++++++++++

From: [e-mail] (Ben Haller)
Date: 9 Sep 92 17:13:19 GMT
Organization: Stick Software

In article <#[e-mail]> [e-mail] writes:
>In article <[e-mail]>,
>  [e-mail] (Ben Haller) writes:
>|>   As several people have already indicated, the two basic methods
>|> are either using the Palette Wrecker (oh, did I say wrecker?  I meant
>|> manager) or using SetEntries.  The thing I want to address is this,
>|> in my mind unwarranted, bias towards the Palette Wrecker (there, I
>|> mistyped it again!)
>Dang.. ya gotta watch them typos, ya know :)
I just keep doing it, I don't know why...but then you seem to mistype
"you" as "u" (not to mention "the" as "teh"...) :->

>|>   If you use it, in the best of all possible worlds, when your application
>|> get context-switched in your palette will be swapped back in, using the
>|> best possible slots in the CLUT taking into consideration the colors
>|> everybody else is using, etc. etc.  This is hogwash - it never happens.
>Granted. The Palette Manager does not care about which slots it
>uses. I don't see why you do.. is there some benefit to particular
>slots that I am not aware of? Id think that CLUT slot is pretty
>much like annother, unless u r XORing things... Of course, u could use
>pmExplicit colors to get specific indicies.
No, the whole point of using the Palette Manager, as far as I can tell
from Inside Mac, is that you will be compatable with other people, to
reduce the amount of CLUT-flashing and such that goes on to a minimum.
Well, not the whole point.  But most of the point.  When you ask for
a certain shade of green, it is supposed to either say "oh, here's a
green that's good enough, use it" or say "well, there's no green close
enough, here's one that I just allocated into the CLUT using a slot nobody
else's palette was using."  The first case works, but then you could've
called Color2Index to find that out.  The second case does not work
unless everybody else running is also using the Palette Manager (not
bloody likely - what proportion of commercial apps do you suppose use
the Palette Manager?)

>|> In my experience using the palette manager means the screen does CLUT
>|> flashes that are even more distracting than they would usually be (i.e.
>|> it will often flash *several times*),
>I have never seen this myself. Can you give an example?
>[ie how can I make it happen?]
No, I can't.  I haven't used the Palette Manager in years.  Anybody want
to give an example, or alternatively tell me I'm full of it?  I may
be full of it, but this was my impression.
  A point in your favor.

>Also, I presume the technique you propound somehow gets the screen
>to redraw, with the new colors. Otherwise, you'd wind up with the
>usual my-background-is-in-briliant-yellow-and-turquoise-and-my-finder-
>icons-are-indecyperable syndrome. This bothers me much more than the
>"flash" the palette manager produces. And things only get weirder, since
>thigns that are redraw/exposed get draw right, but everything else
>is still mauve or something. yeck. :)
Mmm, you can force a refresh, but you would be quite right to point out
that the Palette Manager can do a selective refresh on only the windows
that requested color update refreshes, which is preferable.  A point in
your favor.

>|> you end up with a pretty crappy CLUT
>|> that in no way avoids frequently-used colors, and the other applications
>|> in the system are often permanantly fucked up and don't redraw correctly
>|> from then on.
>Can you give examples of when this happens too? It does not
>happen to the programs I have written that use palettes. Also,
>why dont they have the same prob with direct-clut-changes?
OK, here I think I'm on firm ground.  Applications that are written
correctly using SetEntries install their CLUT on resume events and
replace the CLUT that they overwrote on suspend events, and therefore
applications that depend on having the system CLUT get the system CLUT.
  Application that use the Palette Manager basically get ActivatePalette
called for them when their window comes to front.  *But* - when another
application that doesn't use the Palette Manager *or* SetEntries get
brought to front, the environment is not restored.  The other applications
palette stays in place, and the app that wanted the system palette is
fucked (pardon the expression).
  Now you could say "oh, well that application should have put in a palette
that had the full system palette in it, and then everything would have
worked."  But IMV-152 says "If the front window is an old-style window,
or if it has no assigned palette, the Palette Manager establishes the color
environment using a default palette.  For many simple application the
default palette will suffice."  To me this implies that you are supposed
to be more or less guaranteed the system palette unless you request
something else.  It doesn't seem to work this way.
  Any comments?  As I said, I haven't written an app using the Palette
Wrecker (oops) in a long time, maybe Apple has fixed this sort of thing.
But I seem to recall ResEdit still premanantly fucks up the color
environment (it sort of flips the clut across the line y=x, for
no apparent reason, which confuses the hell out of the Finder), and
presumably it uses the Palette Wrecker.
  Until further notice, I'll count a point for me...

>|>  It just isn't worth it, folks.  Nobody else uses the Palette
>|> Wrecker, and so all of the much-touted benefits simply aren't there (lack
>|> of entry conflicts with other apps, etc.)
>Well, the-no-entry-conflicts thing works for apps that dont use ANY
>clut or palette mucking.. they are forced to redraw, and do so with
>the new colors. This is of course only in my experience, u have
>already said yours differs. It also works for other programs
>that use the palette manager, and it does no harm for those that
>don't, right?
See the discussion above, I believe it *does* harm apps that don't fiddle
with the color environment in any way.

>|>  And it has a lot of drawbacks,
>|> not the least being that's it's slow,
>granted.

>|> it increases your code size,
>how does it do this? U can have a palette in a pltt resources
>and not add ANY code, if u r using GetNewCWindow. You
>can grab palettes from resources with very little
>code. Even if you are assembling one on-the-fly, it doesn't seem
>to me like it takes nearly as much code to allocate, fill in,
>assign and activate a palette as it would to write code to make
>clut-manipulation work on multiple monitors,  on direct devices,
>on b&w machines, etc
OK, perhaps you are right on this.  Point for you.  I was thinking
more of the type of CLUT code I tend to write (take over the screen),
whereas you're talking more about QD-in-a-window.

>By the way, Im talking about the more general case of
>drawing-w/-quickdraw-in-a-window, not just the direct screen drawing
>stuff and the take-over-teh-screen stuff, since you appear to be saying
>"never use teh Palette Wrecker, ever ever ever". I can see (now) why you
>would not want to do this if you are not using windows, quickdraw, etc.
>It would be most pointless, but slow anyway. :)
Yes, I think I stated my case a little more broadly than I should have.
In many cases the Palette Wrecker does save time & effort, and if it's
a little buggy and annoying (a LITTLE?) well, maybe Apple will fix it
someday.

>|> it
>|> looks worse, and it's (in my opinion) meither as aesthetically pleasing
>|> nor as compatable as just saving & setting the CLUT (or part of the CLUT)
>|> on resume events and restoring the parts you changed on suspend events.
>Why do you say this? The palette manager should be able to completely
>change the clut to anything u want, 'cept u have to have black and white
>in the clut. Is that such a big difference?
I recall that when I tried to use the Palette Wrecker (so long ago) to
do stuff, it did not, in fact, like being used to take over very much
of the CLUT.  Everything would be fine until a dialog or something
came up, and then my nice green would suddenly be replaced by an icky
brown (which the dialog didn't even use!)  Of course, this happens with
CLUT setting too, but hey, the Palette Wrecker is supposed to fix such
problems.
  BTW, anybody noticed the charming System 7 bug that when the Color Picker
comes up, after you dismiss it it leaves the CLUT fucked up?  Charming.
They haven't fixed that one yet, have they?

>Anyway, if u r gonna save and restore the clut, how do u force all other
>apps and such to redraw [in teh case where u r not taking over the
>whole screen], and of course also force teh desktop to redraw?
Well, forcing a full refresh is easy, I could post the code if you
really want it.  A few lines.  But only updating the windows that
want a color refresh is not easy, and I conceded that point to you above.

>Also, why is the Palette Manager less compatible than CLUT stuff?
The apps-that-use-the-system-palette problem described above.

>|>   Also, if you're using direct-to-screen as almost everyone does - in a
>|> pixel-oriented paint program or in a video game - then you'll want the
>|> whole CLUT to yourself, in which case the Palette Wrecker (even if it
>|> worked) provides no benefits and all the drawbacks.
>Well, the Palette Manager takes care of multiple-monitor setups for you,
>and direct devices. I thot u'd have to special-case for that if
>u r using SetEntries. This doesn't matter if you are taking over the
>screen, but that drawing program ought to run in a window.
Yes, but...suppose it's an 8-bit paint program, in my opinion it would
be dumb to try to display on a 4-bit or less display, you just want to
leave those monitor's CLUTs alone and paint your window with white on
those monitors.  Which the Palette Wrecker won't do.  A loop that sets
all CLUT-driven 8-bit active screen devices to your CLUT is what you
really want in this case, so the PaletteWrecker does you little good.
  Direct devices, etc. I tend to feel the same way - either they have
enough colors that you can show the 8-bit image on them just doing
matching with Color2Index (why is PmForeColor any better?) or you can't,
in which case you're just going to fill with white.

>|>  Just because Apple says to use the Palette Wrecker doesn't
>|> mean you have to.  There is nothing wrong with SetEntries - at least
>|> nothing that the Wrecker fixes.  So why bother.
>Well, the Palette Manager takes care of a bunch of details for you,
>which I have mentioned, and lets you share palette entries with other
>apps if you like (although this doens't work very well, in my option.
>Its that annoying restriction on the values tolerances can take.. you
>cant have small, non-zero tolerances. bleah) It also (in my experience,
>perhaps yours differs again) can allocate "unused" palette entries- IF
>other apps are using the palette manager. If they aren't, no harm (that
>I know of) done.
All discussed above.  You have a point, as I conceded, and I reduce my
claim somewhat.

>|>   OK, I'm ready for the flames... :->
>I tried to be reasonable, and not flame. Mostly because
>I have the feeling that Im way, way out of my depth
>arguing with you. But what the hey. Now pardon me why
>I go dig up my asbestos underwear. I have a feeling
>my ignorance is about to be rudely exposed. :)
  You were very kind not to flame, given the unwise generality of my
original declaration.  I hope this reply didn't seem too hot either, I
think if it's a matter of one or the other of use being right I'd
give the prize to you.  However, I still feel SetEntries is better when
you're either taking over a monitor entirely, or when you want the whole
CLUT to yourself guaranteed.
  Sorry to waste bandwidth on stupid arguments, folks.  I was in a bad
mood yesterday, and didn't phrase my argument as rationally as I might
have...

- -Ben Haller ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Daniel Norman Johnson)
Date: 9 Sep 92 21:15:31 GMT
Organization: Rensselaer Polytechnic Institute, Troy, NY.

[note that I inserted blank lines all over the place, so I could
 read this stuff]

In article <[e-mail]>, [e-mail] (Ben Haller) writes:
|> In article <#[e-mail]> [e-mail] writes:
|> >In article <[e-mail]>,
|> >  [e-mail] (Ben Haller) writes:
|> >|>   As several people have already indicated, the two basic methods
|> >|> are either using the Palette Wrecker (oh, did I say wrecker?  I meant
|> >|> manager) or using SetEntries.  The thing I want to address is this,
|> >|> in my mind unwarranted, bias towards the Palette Wrecker (there, I
|> >|> mistyped it again!)

|> >Dang.. ya gotta watch them typos, ya know :)

|> I just keep doing it, I don't know why...but then you seem to mistype
|> "you" as "u" (not to mention "the" as "teh"...) :->

Hmm... must be line noise. That's it, yeah... :)

[deletia- Palette Manager gives u best o' all possible worlds. Not. ]
|> >Granted. The Palette Manager does not care about which slots it
|> >uses. I don't see why you do.. is there some benefit to particular
|> >slots that I am not aware of? Id think that CLUT slot is pretty
|> >much like annother, unless u r XORing things... Of course, u could use
|> >pmExplicit colors to get specific indicies.

|> No, the whole point of using the Palette Manager, as far as I can tell
|> from Inside Mac, is that you will be compatable with other people, to
|> reduce the amount of CLUT-flashing and such that goes on to a minimum.
|> Well, not the whole point.  But most of the point.

Well, I would say it has a more important function- to be compatible
with all sorts of wierd hardware, new system versions, etc. SetEntries
and all that can be made compatible, of course, but that sounds
like doing things the hard way.

|>  When you ask for
|> a certain shade of green, it is supposed to either say "oh, here's a
|> green that's good enough, use it" or say "well, there's no green close
|> enough, here's one that I just allocated into the CLUT using a slot nobody
|> else's palette was using."  The first case works, but then you could've
|> called Color2Index to find that out.

Sure. But why bother? [actually, thats a bit of a silly
question. That's what your artile was about. :)]

|>  The second case does not work
|> unless everybody else running is also using the Palette Manager (not
|> bloody likely - what proportion of commercial apps do you suppose use
|> the Palette Manager?)

Id make that "anybody" not "everybody"; if we have 3 apps, A B and C [such
nice names], and A and B use the palette manager and C does not, then
A and B will avoid each others palettes (allegedly. You claim this
does not work; I have never tested it); Neither will avoid the
colors C is using (if any), but you are still deriving some benefit.
Ill get more into what happens to C later, since C is probably
the Finder. :)

|> >|> In my experience using the palette manager means the screen does CLUT
|> >|> flashes that are even more distracting than they would usually be (i.e.
|> >|> it will often flash *several times*),

|> >I have never seen this myself. Can you give an example?
|> >[ie how can I make it happen?]

|> No, I can't.  I haven't used the Palette Manager in years.  Anybody want
|> to give an example, or alternatively tell me I'm full of it?  I may
|> be full of it, but this was my impression.
|>   A point in your favor.

Yay! A Point! That's one! :)
I am also eagerly awaiting instructions on how to muck up the
Palette Manager this way. So if u email it to Ben Haller,
please email it to me too. Thanx.

|> >Also, I presume the technique you propound somehow gets the screen
|> >to redraw, with the new colors. Otherwise, you'd wind up with the
|> >usual my-background-is-in-briliant-yellow-and-turquoise-and-my-finder-
|> >icons-are-indecyperable syndrome. This bothers me much more than the
|> >"flash" the palette manager produces. And things only get weirder, since
|> >thigns that are redraw/exposed get draw right, but everything else
|> >is still mauve or something. yeck. :)

|> Mmm, you can force a refresh, but you would be quite right to point out
|> that the Palette Manager can do a selective refresh on only the windows
|> that requested color update refreshes, which is preferable.  A point in
|> your favor.

Thats 2 points! Im on a roll! Anyway,

Well, maybe *you* can force a refresh. I dont know how. And I have
seen a few comercial apps that dont know how either. Also, it seems
to me that most of the time wasted by the Palette Manager is spent
redrawing teh screen.. in this case do you not invoke a similar penalty
(although probably smaller... I think the PM is wasting more time than
just this)

|> >|> you end up with a pretty crappy CLUT
|> >|> that in no way avoids frequently-used colors, and the other applications
|> >|> in the system are often permanantly fucked up and don't redraw correctly
|> >|> from then on.

|> >Can you give examples of when this happens too? It does not
|> >happen to the programs I have written that use palettes. Also,
|> >why dont they have the same prob with direct-clut-changes?

|> OK, here I think I'm on firm ground.  Applications that are written
|> correctly using SetEntries install their CLUT on resume events and
|> replace the CLUT that they overwrote on suspend events, and therefore
|> applications that depend on having the system CLUT get the system CLUT.

I talk about the question of apps-w/-no-clut-or-palette below. A Lot.
Just one other thing:

Doesn't this depend on the order in which these events happen? Is
it garaounteed that suspends come before resumes? If not, then
you could wind up "saving" the wrong CLUT.

Also, what if you dont want all the colors?

|>   Application that use the Palette Manager basically get ActivatePalette
|> called for them when their window comes to front.  *But* - when another
|> application that doesn't use the Palette Manager *or* SetEntries get
|> brought to front, the environment is not restored.  The other applications
|> palette stays in place, and the app that wanted the system palette is
|> fucked (pardon the expression).

Yes, it is.

|>   Now you could say "oh, well that application should have put in a palette
|> that had the full system palette in it, and then everything would have
|> worked."

Yuck. This is not a good idea, the palette will be loaded backwards or
something.. not in the "standard" order. This slows down copybits!

|>  But IMV-152 says "If the front window is an old-style window,
|> or if it has no assigned palette, the Palette Manager establishes the color
|> environment using a default palette.  For many simple application the
|> default palette will suffice."  To me this implies that you are supposed
|> to be more or less guaranteed the system palette unless you request
|> something else.  It doesn't seem to work this way.

I disagree- the palette manager is trying to let apps SHARE the
palette, so that if apps only allocate (say) 30 colors each,
they can BOTH get their palettes. CLUT manipulation does not do
this in any way I can see. If the system palette was restored whenever
a non-PM app came forward, there would be a lot of flashing and this
palette sharing would be disturbed.

Also, NO app can count on having the "default palette" in Color QD. The
palette manager isn't the only way to mess it up. Some fool user must
still be using a 4-bit display. Or 2 bit. Or 1 bit. In any of these cases,
the palette is quite different from the 8 bit. Further, in 4 and 2 bit
color modes, the palete depends on the current hilight color.
[with truely nasty effects too. Try steting your hilite color to light blue,
switching to 4 bit color and using the fidner. light blue icons! :)]

Apps that dont use the palette manager (or something like that)
have to be able to deal with this sort of thing, as well as having
the color environment switched around on them. The finder is one: it
reverts to 4-bit or b&w icons as needed if the palette gets too warped.

Incidentally, the Finder IS a palette-using app! It has palettes on its
windows (including the desktop, but not including the control panels)
for the LABEL COLORS. But NOT the 34 std-icon-colors. Thats probably
because the finder CAN draw wo/ the color icons- it uses teh black
and white versions, but it CANT draw properly wo/ the label colors.
After all, u can't make an icon "light blue" if theres no light blue in
the palette. This arrangement does little damange to any cool-looking
custom-palette windows int the background, yet gives u a working finder
too.

|>   Any comments?  As I said, I haven't written an app using the Palette
|> Wrecker (oops) in a long time, maybe Apple has fixed this sort of thing.

No, they haven't.

|> But I seem to recall ResEdit still premanantly fucks up the color
|> environment (it sort of flips the clut across the line y=x, for
|> no apparent reason, which confuses the hell out of the Finder), and
|> presumably it uses the Palette Wrecker.
|>   Until further notice, I'll count a point for me...

Go right ahead. It still does that. Like I said, the Palette
Manager doesn't care what slots the colors go in- so it sez
"hey lets slow down copybits by putting the palette in BACKWARDS!"
or something. Quite lame. This only applies to the default palettes,
tho. [other palettes slow down copybits either way]

ResEdit is a little crazy with its palettes- it has the default palette
assigned to a lot of its windows. This makes for loads o flashing,
as is unecessary (as the resedit rarely makes large changes to the
palette, the colored icons would look decent anyway. If they didn't
it would revert to b&w, so its not a big deal.)

[deletia- entirely redundant stuff, see above and below about
      apps that dont have their own palettes :)]

[deletia- its slow, yep it is]
[deletia- it inreases yer code size, no it doesn't, yes it does, etc]
|> OK, perhaps you are right on this.  Point for you.  I was thinking
|> more of the type of CLUT code I tend to write (take over the screen),
|> whereas you're talking more about QD-in-a-window.

Yay, annother point! That's 3 now, isn't it?

[deletia- I am talking about qd-in-a-window, not just direct-to-screen]
|> Yes, I think I stated my case a little more broadly than I should have.
|> In many cases the Palette Wrecker does save time & effort, and if it's
|> a little buggy and annoying (a LITTLE?) well, maybe Apple will fix it
|> someday.

I know of no bugs in it myself (yet) but I dont find it annoying
very often. But I do have one complaint about it:

if you close a window w/ a palette, or remove the palette from it,
nothing happens to the color environment. If I am explicitly
getting RID of a palette, it ought to revert to the default
IMHO. Right now it assumes if you have a palette, u want those
colors until you tell it you want some OTHER colors.

Yech.

[deletia- PM looks worse, why?]
|> I recall that when I tried to use the Palette Wrecker (so long ago) to
|> do stuff, it did not, in fact, like being used to take over very much
|> of the CLUT.  Everything would be fine until a dialog or something
|> came up, and then my nice green would suddenly be replaced by an icky
|> brown (which the dialog didn't even use!)  Of course, this happens with
|> CLUT setting too, but hey, the Palette Wrecker is supposed to fix such
|> problems.

I have never seen this, but it soudns like a bug. I have only
written 1 prog that takes over the whole palette (less black and white),
and it has a dialog box (and about box) and it does not have this
problem.

Can you give me more specifics?

|>   BTW, anybody noticed the charming System 7 bug that when the Color Picker
|> comes up, after you dismiss it it leaves the CLUT fucked up?  Charming.
|> They haven't fixed that one yet, have they?

Nope, they haven't. RRRRGH.

But, if yer window has a palette that palette gets activated, and
u have your colors back anyway. If you dont, I dunno maybe u r just
messed up. Sounds like a bug, to me. I hope they fix it, its a pain.

|> >Anyway, if u r gonna save and restore the clut, how do u force all other
|> >apps and such to redraw [in teh case where u r not taking over the
|> >whole screen], and of course also force teh desktop to redraw?

|> Well, forcing a full refresh is easy, I could post the code if you
|> really want it.  A few lines.  But only updating the windows that
|> want a color refresh is not easy, and I conceded that point to you above.

Well, if its short go ahead, as I have no clue how to do this and
if you covert me to CLUT-manipulation I will need to know. But
does it also updated the desktop?

|> >Also, why is the Palette Manager less compatible than CLUT stuff?
|> The apps-that-use-the-system-palette problem described above.

How's that a compatibility prob? They still work. They dont
have the system palette, but they they already had to deal with
that.

|> >|>   Also, if you're using direct-to-screen as almost everyone does - in a
|> >|> pixel-oriented paint program or in a video game - then you'll want the
|> >|> whole CLUT to yourself, in which case the Palette Wrecker (even if it
|> >|> worked) provides no benefits and all the drawbacks.

|> >Well, the Palette Manager takes care of multiple-monitor setups for you,
|> >and direct devices. I thot u'd have to special-case for that if
|> >u r using SetEntries. This doesn't matter if you are taking over the
|> >screen, but that drawing program ought to run in a window.

|> Yes, but...suppose it's an 8-bit paint program, in my opinion it would
|> be dumb to try to display on a 4-bit or less display, you just want to
|> leave those monitor's CLUTs alone and paint your window with white on
|> those monitors.  Which the Palette Wrecker won't do.  A loop that sets
|> all CLUT-driven 8-bit active screen devices to your CLUT is what you
|> really want in this case, so the PaletteWrecker does you little good.

Just inhibit all 4-bit devices. No problemo.
Well, also inhibit all 2 bit devices. Unless u are nuts.

The drawing in white part has nothing to do with the palette
manager OR clut-fooling.

|>   Direct devices, etc. I tend to feel the same way - either they have
|> enough colors that you can show the 8-bit image on them just doing
|> matching with Color2Index (why is PmForeColor any better?) or you can't,
|> in which case you're just going to fill with white.

I suspect they have enough colors. :)

PmForeColor is not usefull for direct writing, and it is
a little shorter and more compatible (Apple's stamp-o-approval. :)
for QD drawing.

[deletia- stuff about which I have a point, according to Ben H.]
|> >|>   OK, I'm ready for the flames... :->

|> >I tried to be reasonable, and not flame. Mostly because
|> >I have the feeling that Im way, way out of my depth
|> >arguing with you. But what the hey. Now pardon me why
|> >I go dig up my asbestos underwear. I have a feeling
|> >my ignorance is about to be rudely exposed. :)

|>   You were very kind not to flame, given the unwise generality of my
|> original declaration.  I hope this reply didn't seem too hot either, I
|> think if it's a matter of one or the other of use being right I'd
|> give the prize to you.  However, I still feel SetEntries is better when
|> you're either taking over a monitor entirely, or when you want the whole
|> CLUT to yourself guaranteed.

Awwwww twernt nothing.

I now agree that SetEntries is better if u r taking over the whole
screen. It is also the ONLY way to get teh whole palette to yourself.
The Palette Manager will NOT touch white or black, EVER.

|>   Sorry to waste bandwidth on stupid arguments, folks.  I was in a bad
|> mood yesterday, and didn't phrase my argument as rationally as I might
|> have...
|>
|> -Ben Haller ([e-mail])

I suspect this little thread is about to die, since
we agree so much. :)
But if you decide to drop it, please email me that code to
refreshes the whole screen on ya. Id like to know how ya do that,
for everything (including menubar+desktop)

PS my apologies to everyone NOT concered with this for chewing up
all this bandwidth. :) I tried not to be redundant, repetetive or
even repeat myself, really I did. Honestly. But well...

Oh well, here goes nothing. Now where's that send button.. ah..
ther...
- --
            - Dan Johnson
And God said "Jeeze, this is dull"... and it *WAS* dull. Genesis 0:0

These opinions have had all identifiying marks removed, and are untraceable.
You'll never know whose they are.

+++++++++++++++++++++++++++

From: [e-mail] (Juri Munkki)
Date: 9 Sep 92 21:07:29 GMT
Organization: Helsinki University of Technology

The Arashi/Storm source code package was missing at least one file.
I added that file and and cleaned up some other details. (One
minor bug has been fixed.)

The new archive should soon be available on ics.uci.edu. The
directory is pub/mac/think-c/code/. Don't take the file
if it is older than September 9.

If you are planning to write an arcade action game for the Mac
and you are using Think C, I strongly suggest that you take a
look at the Arashi package.

- --
  Juri Munkki                           Windsurf: fast sailing
 [e-mail]                          Macintosh: fast software

+++++++++++++++++++++++++++

From: [e-mail] (Bill Williams)
Date: 10 Sep 92 05:17:31 GMT
Organization: HoloNet (BBS: 510-704-1058)

As much As I can emphasize with Daniel Norman  Johnsonspending time
defending the merits of programming in a logical and proper manner with
the proper tools at his disposal, I feel he is missing the point of what
Ben Haller was trying to really express. HE HATES the inept way Apple
implemented the Pallette Wrecker and it offends him that it has been
changed soo many times in the past and that even today merely setting a
default clut resource with 4 pastell colors of your choice into your
application will make the entire screen FLASH on context switches EVEN ON
A 256 color system. Even in system 7.0, even on a quadra. I know I
experienced it and was sickened. You notice it it for certain when the app
is launching.

But on the other hand Ben Haller loses my respect as a person who has
released products such as Solarian II which (from what I recall) take over
the screen in a VERY UN-MAC manner. I have written graphics routines
intended for inclusion in a flight simulator I might finish one day and
all my routines (lines, ovals, rects, circles, simple polygons, filled and
hollow of the aforementioned) were ALWAYS faster than quickdraw at every
depth, but I designed them to work on movable windows. I do not see ANY
speed advantages in a fixed non-window solution.

I want DAs, menubars, and windows in everything I run, including games.

And my games have to use the mouse a proportional positioning device, like
my hand, rather than a left right toggle switch, or I don't like to play them.

Yes I know that there are right ways to program but people should
recognize that the Pallete Wrecker is currently pretty obnoxious, but we
still should use it.


Not only is the current pallete manager worthless, but Apple had someone
type in the indices to the colors as shipped for the current System 7.0
and the person made a TYPO on one of the crucial grays!!! The color is
ruined and will never be fixed, its value escapes me now but its effect
didn't. It made it IMPOSSIBLE to get TWO DAMN NEUTRAL GRAYS off the system
at times. All I wanted were two grays equal in intensity to the light and
dark grays used in NeXT and OSF Motif. There were actually three different
unrelated problems that week long ago, and the blown index in the default
CLUT might not have been the cause of this second annoying problem.

If your eyes are quick you will learn to see Pallete flash.

Also why all this talk about animating palletes now and then? isn't it (1)
impossible on direct mapped 24 bit devices and (2) only possible at the
end of a device VBL (governing it not only to 60 per second, but IDLING
THE CPU during the wait? (not sure if it waits in the trap or not though))
resulting in an effect leaving 0% free CPU.?


BWilliams

+++++++++++++++++++++++++++

From: [e-mail] (Tim McClarren)
Organization: University of Illinois at Urbana
Date: Thu, 10 Sep 1992 06:31:20 GMT

[e-mail] (Bill Williams) writes:

>But on the other hand Ben Haller loses my respect as a person who has
>released products such as Solarian II which (from what I recall) take over
>the screen in a VERY UN-MAC manner. I have written graphics routines
>intended for inclusion in a flight simulator I might finish one day and
>all my routines (lines, ovals, rects, circles, simple polygons, filled and
>hollow of the aforementioned) were ALWAYS faster than quickdraw at every
>depth, but I designed them to work on movable windows. I do not see ANY
>speed advantages in a fixed non-window solution.

What's the point?  You want to copy and paste into Solarian?  I can't see
any advantages in a game really abiding by all the HIGs.  Perhaps adventure
games, but action games require all your attention anyways.  As for mouse-
positioning, I don't like relative either, but I must say, I would probably
find CQ and Solarian much too easy with absolute positioning (after all,
you'd be able to hyperspace your ship around).
Tim

- --
Tim McClarren     | "...a bajillion brilliant Jobsian lithium licks."
[e-mail]|
[phone]     |

+++++++++++++++++++++++++++

From: [e-mail] (Nick B Triantos)
Date: 10 Sep 92 14:02:47 GMT
Organization: The University at Buffalo

Recently, [e-mail] (Bill Williams) writes:

   Also why all this talk about animating palletes now and then? isn't it (1)
   impossible on direct mapped 24 bit devices and (2) only possible at the
   end of a device VBL (governing it not only to 60 per second, but IDLING
   THE CPU during the wait? (not sure if it waits in the trap or not though))
   resulting in an effect leaving 0% free CPU.?

Well, actually, VBL tasks can be activated 60 times / second, but you specify
how many ticks pass between actual calls to the VBL in <your-VBLTask>.vblCount
Thus, if you only need your routine to pop up 3 times / second, set vblCount to
20. (IM-II, p. 350).  My experience with VBLs is limited only to some ultra-
simplistic testing I did when I first read about them, and so I'm also unsure
about whether the task _MUST_ complete before control is resumed to the main
program.

I'm really enjoying this thread, as I'm in the early stages of programming an
action-style game for the Mac, and I really could use the help (my last game
was on an Apple ][e, and it was in pure 6502 assembler).  If there are other
people out there who have information about the following, I'd love to see what
you have to say about:
 - efficient collision detection algorithms
 - computer strategy heuristics (e.g. when does the monster shoot, when does
   the alien lob a bomb at the player, when does the CPU make the checkmate
   move, etc.  Only some of these things should be purely, random, no?
 - What type of code does the programmer make "reusable" enough that when his
   or her next game comes along, he/she doesn't have to start from scratch
   again
 - Proper use of VBLs, and the other suggestions Joe Holt had made a few days
   ago (uses/abuses of off-screen buffers, clut animation, protecting your
   screen real estate, masking techniques, & assembly language optimizations)

Who knows?  By the time this thread dies out, there may well be another 10-20
worthwhile color action games out for the Mac.

- -Nick
- --
Nick Triantos    internet: [e-mail]
                 AOL:      Triantos
"Scientists tell us that the fastest animal on earth, with a top speed of
120 ft/sec, is a cow that has been dropped out of a helicopter." - Dave Barry

+++++++++++++++++++++++++++

From: [e-mail] (Daniel Norman Johnson)
Date: 10 Sep 92 13:28:38 GMT
Organization: Rensselaer Polytechnic Institute, Troy, NY.

In article <[e-mail]>, [e-mail] (Bill Williams) writes:
|> As much As I can emphasize with Daniel Norman  Johnsonspending time

You can call me Dan. :)

|> defending the merits of programming in a logical and proper manner with
|> the proper tools at his disposal, I feel he is missing the point of what
|> Ben Haller was trying to really express.

I dont think so because....

|> HE HATES the inept way Apple
|> implemented the Pallette Wrecker

I knew this. I just didn't buy his arguement for hating it.

|> and it offends him that it has been
|> changed soo many times in the past

This he didn't say. He probably didn't say it because if it were
true, he wouldn't know it. He doesn't use the Palette Manager, if
you recall. :)

Incidentally, to what changes are you refering? The only ones
I rememeber is that when 32-bit QD came out, the palette manager
learned to deal with direct devices, and when 32 bit QD, version
1.2 appeared pmTolerant+pmExplicit, pmAnimated+pmExplicit and inhibitions
were added. These things have no effect on progs/systems that do not
use these features, of course, so I dont quite see whats wrong.

|> and that even today merely setting a
|> default clut resource with 4 pastell colors of your choice into your
|> application will make the entire screen FLASH on context switches EVEN ON
|> A 256 color system.

This can be true. When teh colors are first activated, there is such a flash.
There will also be flashes on context switches if there aren't
enough colors to go around. However, if we are just talking about 1
app with 4 colors, plus the finder, it shouldn't flash in 256 colors.

Ive never tried this example exactly, but if you'll believe it, 5 colors
(some grays, a green, a red, a light-purple) on a 4 bit display don't
produce this effect. Of course, maybe the Palette Manager just hates
pastel colors. :)

|> Even in system 7.0, even on a quadra.
|> I know I
|> experienced it and was sickened. You notice it it for certain when the app
|> is launching.

Yeah, when teh app launches you DO see the flash, because the
palette is being changed. No getting around it. And the Palette Manager
forces a redraw of all windows that dont tell it not to, and the
desktop, etc, when this happens. I personally think this is better
then just having bizzare colors. Perhaps you disagree.

|> But on the other hand Ben Haller loses my respect as a person who has
|> released products such as Solarian II which (from what I recall) take over
|> the screen in a VERY UN-MAC manner. I have written graphics routines
|> intended for inclusion in a flight simulator I might finish one day and
|> all my routines (lines, ovals, rects, circles, simple polygons, filled and
|> hollow of the aforementioned) were ALWAYS faster than quickdraw at every
|> depth, but I designed them to work on movable windows. I do not see ANY
|> speed advantages in a fixed non-window solution.
|>
|> I want DAs, menubars, and windows in everything I run, including games.
|>
|> And my games have to use the mouse a proportional positioning device, like
|> my hand, rather than a left right toggle switch, or I don't like to play them.
|>

This sounds like personal preference to me. I often like games that
take over teh screen, myself. So there! Nyaa nyaa! :)

|> Yes I know that there are right ways to program but people should
|> recognize that the Pallete Wrecker is currently pretty obnoxious, but we
|> still should use it.

I dunno.. I think we should use it if it helps. Sometimes it doesn't.
Like if u r taking over the whole screen.

|>
|> Not only is the current pallete manager worthless,

Doesn't this contradict what u just said? If its worthless
why use it?

|> but Apple had someone
|> type in the indices to the colors as shipped for the current System 7.0
|> and the person made a TYPO on one of the crucial grays!!!

Which one? I have never noticed this. In any case, there are a lot
of grays so this is not so critical.

|> The color is
|> ruined and will never be fixed,

Huh? why not?

|> its value escapes me now but its effect
|> didn't. It made it IMPOSSIBLE to get TWO DAMN NEUTRAL GRAYS off the system
|> at times.

The palette manager could have netted you any grays you like,
without regard for what is in the various system palettes.

|> All I wanted were two grays equal in intensity to the light and
|> dark grays used in NeXT and OSF Motif. There were actually three different
|> unrelated problems that week long ago, and the blown index in the default
|> CLUT might not have been the cause of this second annoying problem.

Ok.

|> If your eyes are quick you will learn to see Pallete flash.

I can already see the flash, when it happens. Its very dramatic- the whole
screen redraws, in general. Sometimes the desktop refresh isn't very
noticable (its drawing the same pattern onto itself, so if the pattern
wasn't disturbed not much happens) [<- thats just from my observations,
not any real source. Maybe something else happens, but it looks like that]
but the finder windows are erased and redrawn. I can really truely
see this. Honest, honest. :)

|> Also why all this talk about animating palletes now and then? isn't it (1)
|> impossible on direct mapped 24 bit devices and (2) only possible at the
|> end of a device VBL (governing it not only to 60 per second, but IDLING
|> THE CPU during the wait? (not sure if it waits in the trap or not though))
|> resulting in an effect leaving 0% free CPU.?

Color animation is still usefull. It does not work on direct divices,
but Ill wager any 24 bit device can be run in 8 bits too. So put up
a dialog asking if the user wants to switch to 8 bit color, or quit, or
watch the program break.

- --
            - Dan Johnson
And God said "Jeeze, this is dull"... and it *WAS* dull. Genesis 0:0

These opinions have had all identifiying marks removed, and are untraceable.
You'll never know whose they are.

+++++++++++++++++++++++++++

From: [e-mail] (Ross Brown)
Date: 10 Sep 92 14:56:56 GMT
Organization: Bell-Northern Research

In article <[e-mail]> [e-mail] (Nick B
Triantos) writes:
>[stuff deleted]
>Who knows?  By the time this thread dies out, there may well be another 10-20
>worthwhile color action games out for the Mac.

I enjoy games as much as the next guy, but...
Please end the cross-posting, and continue the thread in c.s.m.g only.  Thanks.

==============================================================================
Ross Brown, Dept. 7C22  < Bell-Northern Research     >  Just the facts, ma'am.
Advisor, Telemgmt Svcs  < P. O. Box 3511, Station C  >  We don't care whose
[e-mail]             < Ottawa, ON, Canada K1Y 4H7 >  opinions yours aren't.
==============================================================================

+++++++++++++++++++++++++++

From: [e-mail] (Nick B Triantos)
Date: 10 Sep 92 17:27:54 GMT
Organization: The University at Buffalo

In article <[e-mail]> [e-mail] (Ross Brown) writes:

>>I [Nick Triantos] recently write:
>>[stuff deleted]
>>Who knows?  By the time this thread dies out, there may well be another 10-20
>>worthwhile color action games out for the Mac.

>I enjoy games as much as the next guy, but...
>Please end the cross-posting, and continue the thread in c.s.m.g only.  Thanks.

Most of this thread, including my suggestions in the last posting are directly
related to the PROGRAMMING of games.  What more apropriate newsgroup than
c.s.m.p.?  If you don't like reading them, just add them to a kill file.

Sheesh.

- -Nick
- --
Nick Triantos    internet: [e-mail]
                 AOL:      Triantos
"Scientists tell us that the fastest animal on earth, with a top speed of
120 ft/sec, is a cow that has been dropped out of a helicopter." - Dave Barry

+++++++++++++++++++++++++++

From: [e-mail] (Tim McClarren)
Date: 10 Sep 92 23:12:27 GMT
Organization: University of Illinois at Urbana

[e-mail] (Nick B Triantos) writes:

>In article <[e-mail]> [e-mail] (Ross Brown) writes:

>>>I [Nick Triantos] recently write:
>>>[stuff deleted]
>>>Who knows?  By the time this thread dies out, there may well be another 10-20
>>>worthwhile color action games out for the Mac.

>>I enjoy games as much as the next guy, but...
>>Please end the cross-posting, and continue the thread in c.s.m.g only.  Thanks.

>Most of this thread, including my suggestions in the last posting are directly
>related to the PROGRAMMING of games.  What more apropriate newsgroup than
>c.s.m.p.?  If you don't like reading them, just add them to a kill file.

>Sheesh.

c.s.m.p is the appropriate newsgroup, if anything, it shouldn't be
cross-posted to games.  Anyways, I too would be interested in eff.
collision detection algorithms.
Tim

- --
Tim McClarren     | "...a bajillion brilliant Jobsian lithium licks."
[e-mail]|
[phone]     |

+++++++++++++++++++++++++++

From: [e-mail] (Ben Haller)
Date: 10 Sep 92 23:57:59 GMT
Organization: Stick Software

In article <[e-mail]> [e-mail] writes:
>[huge amounts deleted...]
>Doesn't this depend on the order in which these events happen? Is
>it garaounteed that suspends come before resumes? If not, then
>you could wind up "saving" the wrong CLUT.
>
>Also, what if you dont want all the colors?
  I don't think you can get two suspends or two resumes in a row.  If
you did, I bet a lot more than the CLUT would break, in a lot of
apps...

>Also, NO app can count on having the "default palette" in Color QD. The
>palette manager isn't the only way to mess it up. Some fool user must
>still be using a 4-bit display. Or 2 bit. Or 1 bit. In any of these cases,
>the palette is quite different from the 8 bit. Further, in 4 and 2 bit
>color modes, the palete depends on the current hilight color.
>[with truely nasty effects too. Try steting your hilite color to light blue,
>switching to 4 bit color and using the fidner. light blue icons! :)]
>
>Apps that dont use the palette manager (or something like that)
>have to be able to deal with this sort of thing, as well as having
>the color environment switched around on them. The finder is one: it
>reverts to 4-bit or b&w icons as needed if the palette gets too warped.
Well really this is a part of my problem with their scheme.  If all
you want is the system palette, you can either use the palette manager
to install that palette (gets the colors in the wrong order, slows down
CopyBits), use SetEntries (compatability problems, etc.), or go through
all of these labyrinthine tests to determine whether the clut is within
a sufficient tolerance of the system CLUT.  The Finder (as far as I know
it is still this, 7.0 was...) doesn't actually do a CLUT compare, it
compares the ctSeed value!  Which means if you set the CLUT with SetEntries
and the ctSeed changes (which it always does) the Finder will barf, even
if the CLUT you set is the system CLUT!  No, wait I'm misremembering this.
It checks the ctSeed to see if it *needs* to check the CLUTs.  But if
you're in grayscale, and you set the CLUT to the standard grayscale CLUT
(gray ramp), the ctSeed changes, the Finder does a compare of all the
colors in the current CLUT - but against the *color* CLUT for the bit
depth you're in.  And so of course the compare fails, the color and
grayscale CLUTs being different.  And so all your icons are then 1-bit,
until you tweak the monitor or reboot.  And now I remember, they did
"fix" this problem - they changed the grayscale CLUT to be the same as
the color CLUT, instead of a grayscale ramp!  Love those bug fixes.
  Anyhow, the point is, it should be *easy* to write an app that likes
the default palette.  But as it is, writing such an app is actually
*harder* than writing an app that installs a custom palette (thus causing
flashes, slowness, etc.)  This is not the way things should be.

>Incidentally, the Finder IS a palette-using app! It has palettes on its
>windows (including the desktop, but not including the control panels)
>for the LABEL COLORS. But NOT the 34 std-icon-colors. Thats probably
>because the finder CAN draw wo/ the color icons- it uses teh black
>and white versions, but it CANT draw properly wo/ the label colors.
>After all, u can't make an icon "light blue" if theres no light blue in
>the palette. This arrangement does little damange to any cool-looking
>custom-palette windows int the background, yet gives u a working finder
>too.
  It is also fairly easy to get the finder to permanantly draw the
window backgrounds in beige rather than white (even white is in
entry 0 of the CLUT), and to draw text white-on-black (again, with
a normal CLUT).  Temporarily setting white and black to other colors will
tweak it beyond repair, and then even if you put the system CLUT
back in it will be confused.

>|> In many cases the Palette Wrecker does save time & effort, and if it's
>|> a little buggy and annoying (a LITTLE?) well, maybe Apple will fix it
>I know of no bugs in it myself (yet) but I dont find it annoying
>very often. But I do have one complaint about it:
I think many of the things that you might just consider annoying,
I consider bugs.  A design flaw is a bug.
  I think you also have more patience with Apple than I do...
  But then, how many years is it *supposed* to take until you can
play sounds without crashing, hanging, or silencing the speaker?
It's been 8...

>|> I recall that when I tried to use the Palette Wrecker (so long ago) to
>|> do stuff, it did not, in fact, like being used to take over very much
>|> of the CLUT.  Everything would be fine until a dialog or something
>|> came up, and then my nice green would suddenly be replaced by an icky
>|> brown (which the dialog didn't even use!)  Of course, this happens with
>|> CLUT setting too, but hey, the Palette Wrecker is supposed to fix such
>|> problems.
>I have never seen this, but it soudns like a bug. I have only
>written 1 prog that takes over the whole palette (less black and white),
>and it has a dialog box (and about box) and it does not have this
>problem.
  I'm quite certain of this.  Just set the CLUT to, say, a ramp from
white to black, and then bring up some dialogs and stuff.  This is
System 6 & 7.  It will shove nasty colors in there and not take them
out.  Very annoying.  At least, it does it on my machine :->

>|> >Anyway, if u r gonna save and restore the clut, how do u force all other
>|> >apps and such to redraw [in teh case where u r not taking over the
>|> >whole screen], and of course also force teh desktop to redraw?
>
>|> Well, forcing a full refresh is easy, I could post the code if you
>|> really want it.  A few lines.  But only updating the windows that
>|> want a color refresh is not easy, and I conceded that point to you above.
>
>Well, if its short go ahead, as I have no clue how to do this and
>if you covert me to CLUT-manipulation I will need to know. But
>does it also updated the desktop?
Here's the code:

void InvalScreen()
{
    DrawMenuBar();
    PaintOne(0L,GrayRgn);
    PaintBehind(WindowList,GrayRgn);
}

I believe this is the only code I have ever posted that is copied
directly from Solarian II, so all you people who have been slavering
over the (imagined) prospect of getting Sol source out of my tight
little fists, rejoice!
  It does redraw the desktop.  It also seems to work in MultiFinder,
for reasons that I free admit to not understanding.  I wish they
would document what the window manager *means* in MultiFinder...

>|> those monitors.  Which the Palette Wrecker won't do.  A loop that sets
>|> all CLUT-driven 8-bit active screen devices to your CLUT is what you
>|> really want in this case, so the PaletteWrecker does you little good.
>
>Just inhibit all 4-bit devices. No problemo.
>Well, also inhibit all 2 bit devices. Unless u are nuts.
>
>The drawing in white part has nothing to do with the palette
>manager OR clut-fooling.
So the Palette Manager lets you say "this is the palette I want for this
window, but only touch windows that are 8-bit"?  I had no idea.  That's
nice.

>I now agree that SetEntries is better if u r taking over the whole
>screen. It is also the ONLY way to get teh whole palette to yourself.
>The Palette Manager will NOT touch white or black, EVER.
One of the more obscure areas of knowledge is "which parts of
QuickDraw continue to work when black and white are not in their
accustomed places?"  Due to a stupid design flaw in Solarian II,
I'm pretty familiar with this issue...

  Amusing fact: you, and so many others, dread going as low-level as
SetEntries.  Me, I've had to resort to calling the video driver
directly, because I considered SetEntries too slow...  And recently
I've been wondering if there isn't a way to get even lower-level -
some of those video drivers are pretty badly written, if you want to
get 60-75 CLUT switches a second...

  So, pretty much the end of this thread, I think...

- -Ben Haller ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Ben Haller)
Date: 11 Sep 92 00:21:17 GMT
Organization: Stick Software

In article <[e-mail]> [e-mail] (Bill Williams) writes:
>...I feel he is missing the point of what
>Ben Haller was trying to really express. HE HATES the inept way Apple
>implemented the Pallette Wrecker and it offends him...
Thank you, you expressed this very nicely.

>But on the other hand Ben Haller loses my respect as a person who has
>released products such as Solarian II which (from what I recall) take over
>the screen in a VERY UN-MAC manner. I have written graphics routines
>intended for inclusion in a flight simulator I might finish one day and
>all my routines (lines, ovals, rects, circles, simple polygons, filled and
>hollow of the aforementioned) were ALWAYS faster than quickdraw at every
>depth, but I designed them to work on movable windows. I do not see ANY
>speed advantages in a fixed non-window solution.
  Oh, no, no speed advantages.  That isn't why I designed Solarian II
the way I did.  I have written *many* graphics routines that are
origin independant, do region clipping, etc.  That isn't the problem.
  The reason Solarian II has no Mac interface is that it is supposed to
look like an arcade game.  As far as I'm concerned, things like
menubar, windows from other applications, etc. are pure distraction
when you're trying to play a video game, and they also ruin the mood
of the game.  Video games should look like the games you play in
a real video arcade, if possible.  I only regret that the Mac doesn't
ship with a joystick...
  I think this point of view is quite defensible...imagine if you're
trying to play a game using the mouse, and you accidentally click outside
of it's correctly-Mac-interfacey window, do a context, and your enemies
kick your ass while you're fumbling around trying to get back to the
game (you could say "pause the game", but it's still annoying, and what
about networked games?  You could say "hide the menubar during play"
and stuff, but then isn't this exactly what Solarian II does?)
  I think it's even more defensible from an aesthetic view...

>I want DAs, menubars, and windows in everything I run, including games.
  Well, I think you're in a minority.  And in any case, I make
aesthetic decisions based on *my* aesthetics, which makes the point moot -
I consider the choice I made to be correct, public opinion be damned.

>And my games have to use the mouse a proportional positioning device, like
>my hand, rather than a left right toggle switch, or I don't like to play them.
  A "left right toggle switch" being the way Solarian II works?
Actually, Solarian's mouse control is more subtle than this, and it was
very carefully designed.  You would hate life if Solarian II used the mouse
as a "proportional positioning device", you wouldn't be able to move
continuously...
  Well, wait.  Do you absolute positioning or relative positioning?  Really,
there are so many way to use the mouse, different ways suit different games
or applications, and I think it's dumb to say "I hate all games that don't
use the mouse *my* way."  The way Crystal Quest uses the mouse feels
very difficult to control initially, but after you get good at it it gives
you the perfect kind of control for the game.  I think that the mouse
control is probably my favorite thing about that game.

>Yes I know that there are right ways to program but people should
>recognize that the Pallete Wrecker is currently pretty obnoxious, but we
>still should use it.
  Why bother?  When they fix it, they'll probably put a whole new API
on, that seems to be what they do with things as broken as it is...
  Oh, but we've argued this to death, don't let's reopen it...

>Not only is the current pallete manager worthless, but Apple had someone
>type in the indices to the colors as shipped for the current System 7.0
>and the person made a TYPO on one of the crucial grays!!! The color is
>ruined and will never be fixed, its value escapes me now but its effect
>didn't. It made it IMPOSSIBLE to get TWO DAMN NEUTRAL GRAYS off the system
>at times. All I wanted were two grays equal in intensity to the light and
>dark grays used in NeXT and OSF Motif.
Here you are on drugs, I believe (metaphorically, at least).  The
System 7 CLUT is just fine.  I feel pretty sure of this.  Want to
specify which color you think is bad?  The grayscale ramp at the end
of the CLUT isn't *supposed* to be a smooth ramp, you know.  The
missing grays are to be found elsewhere in the CLUT.  And you know,
I'd be incredibly surprised if they had someone *type in* the CLUT
values, since it can be (much more easily) generated with a few lines
of code, being a simple algorithmically-generable color set...

>Also why all this talk about animating palletes now and then? isn't it (1)
>impossible on direct mapped 24 bit devices and (2) only possible at the
>end of a device VBL (governing it not only to 60 per second, but IDLING
>THE CPU during the wait? (not sure if it waits in the trap or not though))
>resulting in an effect leaving 0% free CPU.?
  It is impossible on 24-bit devices, although on these you can do
gamma animation instead (although the Palette Manager doesn't support this)
 Some video drivers wait on the VBL, some don't.  Which is very annoying.
But all you have to do (all you have to do - it's easy!) is do all of your
other processing at interrupt time, and then you'll be fine, the delay loop
in the video driver won't bother you at all...
  It should also be possible to use a combination of a slotVBL and a
Time Manager task (and a Deferred Task too, I suppose) to get rid
of the delay loop...

- -Ben Haller ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Ben Haller)
Date: 11 Sep 1992 00:30:45 GMT
Organization: Stick Software

In article <[e-mail]> [e-mail] (Nick B Triantos) writes:
>Recently, [e-mail] (Bill Williams) writes:
>   Also why all this talk about animating palletes now and then? isn't it (1)
>   impossible on direct mapped 24 bit devices and (2) only possible at the
>   end of a device VBL (governing it not only to 60 per second, but IDLING
>   THE CPU during the wait? (not sure if it waits in the trap or not though))
>   resulting in an effect leaving 0% free CPU.?
>
>Well, actually, VBL tasks can be activated 60 times / second, but you specify
>how many ticks pass between actual calls to the VBL in <your-VBLTask>.vblCount
>Thus, if you only need your routine to pop up 3 times / second, set vblCount to
>20. (IM-II, p. 350).  My experience with VBLs is limited only to some ultra-
>simplistic testing I did when I first read about them, and so I'm also unsure
>about whether the task _MUST_ complete before control is resumed to the main
>program.
  No, he's not talking about calling SetEntries from a VBL, he's talking
about the SetEntries routine (or actually, the video driver) waiting in a
tight loop for the gun to get to a certain point before doing the
SetEntries operation.  See my other post in this thread (no, not that other
post, the *other* other post - god this is a busy thread!)

>I'm really enjoying this thread, as I'm in the early stages of programming an
>action-style game for the Mac, and I really could use the help (my last game
>was on an Apple ][e, and it was in pure 6502 assembler).  If there are other
>people out there who have information about the following, I'd love to see what
>you have to say about:

> - efficient collision detection algorithms
  My current favorite is, keep a sorted list of sprites (keeping it
sorted, assuming your sprites don't constantly teleport, is O(n)) and
compare nearby elements in the sorted list (again, O(n) for normal cases).
If you get a bounding box intersection, do a mask compare.  This is
pretty efficient, I think.  I hope...

> - computer strategy heuristics (e.g. when does the monster shoot, when does
>   the alien lob a bomb at the player, when does the CPU make the checkmate
>   move, etc.  Only some of these things should be purely, random, no?
You certainly need non-random elements.  I usually have things like a
time delay that the enemy has to wait before firing again, things
like that.  You will find that it's easy to make bad guys that cream
human players.  The hard thing is to make well-balanced enemies, or
enemies that behave in an interesting way.  Books could be written
on this subject...

> - What type of code does the programmer make "reusable" enough that when his
>   or her next game comes along, he/she doesn't have to start from scratch
Everything you can!  I generally don't even attempt to make the
display code general beyond a reasonable point, it is just a fact
of life that virtually every game requires you to rewrite your
graphics code...assuming you want to be fast...
  Everything about dealing with keyboard/mouse, displays, high scores,
sounds, etc etc should be as portable as possible.
  The logic that moves the bad guys and stuff will be game-specific,
unless you want the same bad guy in two games...

> - Proper use of VBLs, and the other suggestions Joe Holt had made a few days
>   ago (uses/abuses of off-screen buffers, clut animation, protecting your
>   screen real estate, masking techniques, & assembly language optimizations)
  Boy, quite a bit could be written about all this.  Want to ask a slightly
less broad question relating to something you're actually trying to
do *right now*?  Just to narrow it down a bit...

- -Ben Haller ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Daniel Norman Johnson)
Date: 11 Sep 92 01:57:12 GMT
Organization: Rensselaer Polytechnic Institute, Troy, NY.

In article <[e-mail]>, [e-mail] (Ben Haller) writes:
|> In article <[e-mail]> [e-mail] writes:
|> >[huge amounts deleted...]
|> >Doesn't this depend on the order in which these events happen? Is
|> >it garaounteed that suspends come before resumes? If not, then
|> >you could wind up "saving" the wrong CLUT.
|> >
|> >Also, what if you dont want all the colors?
|>   I don't think you can get two suspends or two resumes in a row.  If
|> you did, I bet a lot more than the CLUT would break, in a lot of
|> apps...

My apps wouldn't, but that's beside the point.

This is not the case I was talking about. Let me try again.

Lets say we have two apps that use clut switching, instead of
palette wrecking or just taking their punishment like a good
little app. :)

Call them "Mongo Colors" and "Freds Neato Picture Program". Just to
waste bandwidth. :)

Start 'em both. Say mongo-colors is in front, and so far all is well.
Now bring Freds Picture Prog to the front. NOW, if Mong-Colors
gets a suspend and THEN fred's gets a resume, all is well.

If freds gets a resume, THEN mongo gets a suspend, things are not well.
Because fred will resume and save the "old" color environment, and
institute its own. the environment it is saving however is really
mongos! Then mongo replaces "its" environment with ITS saved version.
But its really replaces freds, which will mess fred up of course. AND
it will throw sand in the wheels of the mechanism that restores
freds palette, since its restoring the wrong thing. Mongo remains
blissfully ignorant tho.

However, is the order is guarantted to be suspend then resume,
all is well. Is it? [alternaately, maybe I have no clue.]

|> >Also, NO app can count on having the "default palette" in Color QD. The
|> >palette manager isn't the only way to mess it up. Some fool user must
|> >still be using a 4-bit display. Or 2 bit. Or 1 bit. In any of these cases,
|> >the palette is quite different from the 8 bit. Further, in 4 and 2 bit
|> >color modes, the palete depends on the current hilight color.
|> >[with truely nasty effects too. Try steting your hilite color to light blue,
|> >switching to 4 bit color and using the fidner. light blue icons! :)]
|> >
|> >Apps that dont use the palette manager (or something like that)
|> >have to be able to deal with this sort of thing, as well as having
|> >the color environment switched around on them. The finder is one: it
|> >reverts to 4-bit or b&w icons as needed if the palette gets too warped.

|> Well really this is a part of my problem with their scheme.  If all
|> you want is the system palette, you can either use the palette manager
|> to install that palette (gets the colors in the wrong order, slows down
|> CopyBits), use SetEntries (compatability problems, etc.), or go through
|> all of these labyrinthine tests to determine whether the clut is within
|> a sufficient tolerance of the system CLUT.

This can be done for your by the palette manager. Convert the default
clut you want to a palette, set all of its tolerances to something
reasonable, set the usage to pmTolerant. It will do nothing
in the case that the system palette IS there, and will fix the
palette in case it isn't.

|>  The Finder (as far as I know
|> it is still this, 7.0 was...) doesn't actually do a CLUT compare, it
|> compares the ctSeed value!  Which means if you set the CLUT with SetEntries
|> and the ctSeed changes (which it always does) the Finder will barf, even
|> if the CLUT you set is the system CLUT!  No, wait I'm misremembering this.
|> It checks the ctSeed to see if it *needs* to check the CLUTs.  But if
|> you're in grayscale, and you set the CLUT to the standard grayscale CLUT
|> (gray ramp), the ctSeed changes, the Finder does a compare of all the
|> colors in the current CLUT - but against the *color* CLUT for the bit
|> depth you're in.  And so of course the compare fails, the color and
|> grayscale CLUTs being different.  And so all your icons are then 1-bit,
|> until you tweak the monitor or reboot.  And now I remember, they did
|> "fix" this problem - they changed the grayscale CLUT to be the same as
|> the color CLUT, instead of a grayscale ramp!  Love those bug fixes.

This is NOT at all what happens on my mac anyway. Gray scale
still means gray ramp. the finder icons still draw right. They
draw they way they would if resedit had reversed the palette on them-
a bit slower. Because they need to compare RGB values and all that.
They do NOT revert to b&w! [however, u'd think it could use the 8 bit
icons in 4 bit mode when in grayscale, and it does not do this]

|>   Anyhow, the point is, it should be *easy* to write an app that likes
|> the default palette.  But as it is, writing such an app is actually
|> *harder* than writing an app that installs a custom palette (thus causing
|> flashes, slowness, etc.)  This is not the way things should be.

Funny, I find it easier not to use the palette, despite the fact
that I cannot assume that I will have exactly the colors I expect.
I have to use device-independant methods to do everything- the moreso
the better. MakeRGBPat, fer instance. icon families. That sorta thing.

|> >Incidentally, the Finder IS a palette-using app! It has palettes on its
|> >windows (including the desktop, but not including the control panels)
|> >for the LABEL COLORS. But NOT the 34 std-icon-colors. Thats probably
|> >because the finder CAN draw wo/ the color icons- it uses teh black
|> >and white versions, but it CANT draw properly wo/ the label colors.
|> >After all, u can't make an icon "light blue" if theres no light blue in
|> >the palette. This arrangement does little damange to any cool-looking
|> >custom-palette windows int the background, yet gives u a working finder
|> >too.
|>   It is also fairly easy to get the finder to permanantly draw the
|> window backgrounds in beige rather than white (even white is in
|> entry 0 of the CLUT), and to draw text white-on-black (again, with
|> a normal CLUT).  Temporarily setting white and black to other colors will
|> tweak it beyond repair, and then even if you put the system CLUT
|> back in it will be confused.

This may be why the palette manager will never let you change black
or white. [is that what u mean? if u change black or white the
finder is mucked up beyond repair?]

I dont know of any way to use the Palette MAnager to muck up the finder
beyond repair.

[a little deletia]
|> >I know of no bugs in it myself (yet) but I dont find it annoying
|> >very often. But I do have one complaint about it:
|> I think many of the things that you might just consider annoying,
|> I consider bugs.  A design flaw is a bug.

Perhaps so.

|>   I think you also have more patience with Apple than I do...
|>   But then, how many years is it *supposed* to take until you can
|> play sounds without crashing, hanging, or silencing the speaker?
|> It's been 8...

Rrrrgh! Dont remind me.. I had to shelve a good project (it played
sounds in the background) cuz I could not get the sound manager to
behave.

I DO consider this a bug.

|> >|> I recall that when I tried to use the Palette Wrecker (so long ago) to
|> >|> do stuff, it did not, in fact, like being used to take over very much
|> >|> of the CLUT.  Everything would be fine until a dialog or something
|> >|> came up, and then my nice green would suddenly be replaced by an icky
|> >|> brown (which the dialog didn't even use!)  Of course, this happens with
|> >|> CLUT setting too, but hey, the Palette Wrecker is supposed to fix such
|> >|> problems.
|> >I have never seen this, but it soudns like a bug. I have only
|> >written 1 prog that takes over the whole palette (less black and white),
|> >and it has a dialog box (and about box) and it does not have this
|> >problem.
|>   I'm quite certain of this.  Just set the CLUT to, say, a ramp from
|> white to black, and then bring up some dialogs and stuff.  This is
|> System 6 & 7.  It will shove nasty colors in there and not take them
|> out.  Very annoying.  At least, it does it on my machine :->

But it doesn't do it on mine. Then again, I set the palette not the CLUT,
so maybe that clues it in. Or maybe not. It still has never happened to
me, and I have tried to use dialogs with the entire palette allocated.

[deletia- code to refresh whole screen. go read it yerself. :) ]

Thanks!

[deletia- about getting the palette manager not to touch certain depths]

|> >I now agree that SetEntries is better if u r taking over the whole
|> >screen. It is also the ONLY way to get teh whole palette to yourself.
|> >The Palette Manager will NOT touch white or black, EVER.

[deletia- about not touching b&w]

|>   Amusing fact: you, and so many others, dread going as low-level as
|> SetEntries.

Oh, thats a little strong. I prefer not to go so low.. makes my life
more difficult that it has to be.. but I am not exactly cowering in the
closet afraid my Mac will come and get me if I dare to violate the
CLUT. :)

|>  Me, I've had to resort to calling the video driver
|> directly, because I considered SetEntries too slow...  And recently
|> I've been wondering if there isn't a way to get even lower-level -
|> some of those video drivers are pretty badly written, if you want to
|> get 60-75 CLUT switches a second...

Well, this probably would send me scrabling for my closet. :)

|>  So, pretty much the end of this thread, I think...

That may be. Im not placing any bets yet.
- --
copying            - Dan Johnson
And God said "Jeeze, this is dull"... and it *WAS* dull. Genesis 0:0

These opinions have had all identifiying marks removed, and are untraceable.
You'll never know whose they are.

+++++++++++++++++++++++++++

From: [e-mail] (Tim McClarren)
Organization: University of Illinois at Urbana
Date: Fri, 11 Sep 1992 02:35:57 GMT

[e-mail] (Ben Haller) writes:

>> - efficient collision detection algorithms
>  My current favorite is, keep a sorted list of sprites (keeping it
>sorted, assuming your sprites don't constantly teleport, is O(n)) and
>compare nearby elements in the sorted list (again, O(n) for normal cases).
>If you get a bounding box intersection, do a mask compare.  This is
>pretty efficient, I think.  I hope...

This seems to be the de-facto way of doing it.  I'd love to hear
from someone who hasn't used this method.  Is there another method?
What about geometric approaches?  Break the list in two, break those
lists in two, etc.  But now you've got to keep track of when it's
time for objects to jump lists.  I think the boundaries become
problematic in those cases, no?  Or how about breaking the universe
into radial areas?  Or does that involve too much expensive trigonometry?
And the center gets really nasty.  Also, what about "walls" or other
non-moving obstacles?  For the case of walls, does one simply break them
up into rectangles?  Is that the best?

What about hashing?  Can that be done?  Hash on some absolute location
every time through the loop for each object, and just compare those
objects that hash to the same place.  It seems like this could be
really fast (O(n)) and easy to implement.  And you don't have to worry
about those damned sorted lists :o).
- --
Tim McClarren     | "...a bajillion brilliant Jobsian lithium licks."
[e-mail]|
[phone]     |

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 12 Sep 92 06:40:49 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Ben Haller) writes:
> In article <[e-mail]> [e-mail] writes:
>>|> I recall that when I tried to use the Palette Wrecker (so long ago) to
>>|> do stuff, it did not, in fact, like being used to take over very much
>>|> of the CLUT.  Everything would be fine until a dialog or something
>>|> came up, and then my nice green would suddenly be replaced by an icky
>>|> brown (which the dialog didn't even use!)  Of course, this happens with
>>|> CLUT setting too, but hey, the Palette Wrecker is supposed to fix such
>>|> problems.
>>I have never seen this, but it soudns like a bug. I have only
>>written 1 prog that takes over the whole palette (less black and white),
>>and it has a dialog box (and about box) and it does not have this
>>problem.
>   I'm quite certain of this.  Just set the CLUT to, say, a ramp from
> white to black, and then bring up some dialogs and stuff.  This is
> System 6 & 7.  It will shove nasty colors in there and not take them
> out.  Very annoying.  At least, it does it on my machine :->

Short of using the  pmExplicit flag, the Palette Manager only guarantees to
make available certain *sets* of colours--nowhere does it say that it will
make them available at particular locations in the colour table, or in a
particular order. If it doesn't take out those colours, it's because the
window you are switching to finds them acceptable. It may not return to
exactly the same CLUT configuration that you saw the previous time that same
window was frontmost, but that's because the Palette Manager does the minimum
amount of rearranging necessary each time.

> void InvalScreen()
> {
>     DrawMenuBar();
>     PaintOne(0L,GrayRgn);
>     PaintBehind(WindowList,GrayRgn);
> }

The PaintOne call is redundant; PaintBehind does it all. Also, why refer
to the WindowList when you can use FrontWindow?

Also, there's a problem with this code: Contrary to what IM1 may lead you to
believe, PaintBehind does not preserve the current GrafPort (don't know if
this is fixed in System 7).

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
I'm not fond of benchmarks. I prefer my schmarks to be straight.

+++++++++++++++++++++++++++

From: [e-mail] (Bill Williams)
Organization: HoloNet (BBS: 510-704-1058)
Date: Fri, 11 Sep 1992 07:01:44 GMT

>As for mouse-positioning, I don't like relative either,
but I must say, I would probably ... too easy.


I think that crippling an interface to add challenge to be ghastly! Its
what turns "Vette" into a piece of crap with 9 position steering only and
no proportional positioning.

If you add proportional positioning to a game such as Solarian II which
lacks it and (I feel) suffers from it, then you can add more attackers and
more things to do to add "challenge"

an arcade interface should never appear crippled, erratic, choppy, or
delayed. An arcade interface SHOULD ALWAYS BE FAST AND PROPORTIONALLY
POSITIONAL. Even most of the Apple II games I had since 1979 were
not 8-way Atari-style joystick activated... well at least not the ones I
liked.

Ask anyone who doesn't like Solarian, not those that do enjoy it, what
they don't like and I'll bet a lot don't like the non-proportianal mouse
as being the only configuration allowed.

BWilliams


+++++++++++++++++++++++++++

From: [e-mail] (Tim McClarren)
Organization: University of Illinois at Urbana
Date: Fri, 11 Sep 1992 08:10:10 GMT

[e-mail] (Bill Williams) writes:

>If you add proportional positioning to a game such as Solarian II which
>lacks it and (I feel) suffers from it, then you can add more attackers and
>more things to do to add "challenge"

Well, what's proportional positioning anyways?  I've not heard that
term used.  But, if you mean absolute positioning, then I disagree.
It's not as cut and dried as that.  If you change the positioning,
you affect the entire way in which the game as a whole works.  And
it may simply not be possible to add more attackers.  Maybe it just
bogs when you do...perhaps Ben can answer that.  Because you can't
learn the skill necessary to move the ship doesn't mean it's a bad
way to do positioning :o).

>an arcade interface should never appear crippled, erratic, choppy, or
>delayed. An arcade interface SHOULD ALWAYS BE FAST AND PROPORTIONALLY
>POSITIONAL. Even most of the Apple II games I had since 1979 were
>not 8-way Atari-style joystick activated... well at least not the ones I
>liked.

Hmm...this is strange.  Most of the people I talk to don't like
analog devices for positioning.  In fact, I can't think of a good
arcade game in recent memory that used an analog device.  Except
for maybe the games with steering wheels.  Actually, you're arguing
both ways, first you talk about arcade interfaces, which are generally
digital, and then you use the Apple II games as an example, which
were all analog...so which is it?  And anyways, who says an arcade
interface should always be fast and proportional?  Space Invaders and
PacMan (two of the most successful arcade games) both use relative
positioning.  The Atari's were all digital, Nintendo is digital.
It's impossible to absolute positioning on these (absolute in a fashion
that would allow for more than 8 or so locations).

Solarian doesn't really work in the same way as either of these,
but I would say that it somewhat resembles the way in which a digital
joystick works.  I think that's what Ben was aiming for.  Maybe
he can comment further.  But we're getting into c.s.m.g material
here and not c.s.m.p material.
- --
Tim McClarren     | "...a bajillion brilliant Jobsian lithium licks."
[e-mail]|
[phone]     |

+++++++++++++++++++++++++++

From: [e-mail] (Ben Haller)
Date: 11 Sep 92 17:55:19 GMT
Organization: Stick Software

In article <[e-mail]> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>In article <[e-mail]>, [e-mail] (Ben Haller) writes:
>> In article <[e-mail]> [e-mail] writes:
>> void InvalScreen()
>> {
>>     DrawMenuBar();
>>     PaintOne(0L,GrayRgn);
>>     PaintBehind(WindowList,GrayRgn);
>> }
>
>The PaintOne call is redundant; PaintBehind does it all. Also, why refer
>to the WindowList when you can use FrontWindow?
  The PaintOne call, if I recall correctly, repaints the desktop.  This
would not be done by the PaintBehind call, as far as I know.  IM I-297
says "PaintBehind calls PaintOne for startWindow and all the *windows*
behind startWindow..."  It does not paint the desktop, that needs to
be done explicitly (because the desktop has no update region, so calling
PaintBehind would just have to repaint the whole desktop every time, which
would be slow and lame).
  WindowList: hmm, hadn't thought about it.  Old code.  However, this is
at least *slightly* less likely to skip over a window, for example a
GhostWindow (yes, I know nobody uses those) or a window that has been
"removed" from the window list with a patch to FrontWindow, or something
like that.  Basically no reason, I suppose.

>Also, there's a problem with this code: Contrary to what IM1 may lead you to
>believe, PaintBehind does not preserve the current GrafPort (don't know if
>this is fixed in System 7).
  Yeah, I don't regard it as a problem because I call it in Solarian II
right before doing an ExitToShell, so...what do I care?  But for others,
that's a good point (if true, I don't know...)

- -Ben Haller ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Ben Haller)
Date: 11 Sep 92 18:15:52 GMT
Organization: Stick Software


  Boy, this is a fun thread.

In article <timm.716178957@void> [e-mail] (Tim McClarren) writes:
>[e-mail] (Ben Haller) writes:
>>> - efficient collision detection algorithms
>>  My current favorite is, keep a sorted list of sprites (keeping it
>>sorted, assuming your sprites don't constantly teleport, is O(n)) and
>>compare nearby elements in the sorted list (again, O(n) for normal cases).
>>If you get a bounding box intersection, do a mask compare.  This is
>>pretty efficient, I think.  I hope...
>
>This seems to be the de-facto way of doing it.  I'd love to hear
>from someone who hasn't used this method.  Is there another method?
>What about geometric approaches?  Break the list in two, break those
>lists in two, etc.  But now you've got to keep track of when it's
>time for objects to jump lists.  I think the boundaries become
>problematic in those cases, no?  Or how about breaking the universe
>into radial areas?  Or does that involve too much expensive trigonometry?
>And the center gets really nasty.  Also, what about "walls" or other
>non-moving obstacles?  For the case of walls, does one simply break them
>up into rectangles?  Is that the best?
  Hmm.  Most of these ideas are not so hot, I think.  Why would you
*want* to break the list into parts?  Why would you *want* to use
radial areas (assuming your game isn't radially-based, like Tempest or
something)?
  Walls are generally a separate issue.  Depending on what kind of walls
you have, you might have an array representing where the walls are in
your world so you can do an array look-up to see if a particular area
contains a wall, or you might treat them as sprites and keep them in the
collision list (this would usually not be appropriate, however), or maybe
some other way...
  I think the sorted list approach makes a hell of a lot of sense, as
does your hash table idea.  I would also be interesting in hearing
alternatives.
  Of course, once you get a bounding box intersection (or a hash table
collision, as the case may be) you don't need to do a *mask* compare, you
could do a polygon-polygon intersection, or a circle-intersection test,
or various things like that...

>What about hashing?  Can that be done?  Hash on some absolute location
>every time through the loop for each object, and just compare those
>objects that hash to the same place.  It seems like this could be
>really fast (O(n)) and easy to implement.  And you don't have to worry
>about those damned sorted lists :o).
  Well, when I was typing up there it seemed like a good idea.  But now
it doesn't.  Why not?  Well imagine starting at x=10.  That hashes to a
particular value.  Now presumably you want nearby coordinates to hash to
the same value (so you do, in fact, detect a collision), so x=11 would
probably hash to the same value.  Continue upwards until your hash function
produces a different value, at say x=20.  Now.  Suppose you have a sprite
at x=19 and one at x=20.  Clearly they should collide, but they hash to
different values.  So how do you detect the collision?
  Also: what exactly are you hashing on?  The center of the sprite?  The
left edge?  What about sprites that are very wide, such that they collide
with objects that hash several places away?  Etc.

- -Ben Haller ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 11 Sep 92 19:38:26 GMT
Organization: Kalamazoo College

[e-mail] (Ben Haller) writes:
>  Boy, this is a fun thread.

Hope that wasn't sarcastic...

>  I think the sorted list approach makes a hell of a lot of sense, as
>does your hash table idea.  I would also be interesting in hearing
>alternatives.

For a physical simulation program a few years back, I had to detect
collisions with spheres very quickly.  I put together a lookup table in
which the spheres in a given square were stored in a linked list;  the
length of the edge of each square was equal to the radius of the sphere.
(Actually, it was in 3-space, and I ended up making the edge half again
as long for speed's sake, and the spheres' locations were
pseudo-randomly generated not stored in a table, but the principle's
the same.)

So, if you have an object whose center is 0,0, and the sum of its radius [*]
and the radius of the longest object in the game is x, you only have to
search the linked lists that contain the objects in the rectangle (-x,
- -x, x, x).  Obviously, the unit of measure should not be 1 pixel.  It
should be large enough that you don't waste too much time searching
empty lists and relocating objects from one list to the other.  And it
should be small enough that you don't waste too much time searching
overly long lists.

[*] Define radius however you want, of course.  It might be appropriate
to have an x and a y radius, so you'd search in the rect (-x, -y, x, y).
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 So I'm rattling the bars around this drink-tank discreetly;  I should pour up
 through the keyhole or evaporate completely, but there'd be no percentage and
 there'd be no proof, and the sound upon the roof is only water...      - TMBG

+++++++++++++++++++++++++++

From: [e-mail] (hui  dong)
Organization: University of Chicago Computing Organizations
Date: Sun, 13 Sep 1992 08:41:08 GMT

I am also very interested in creating fast animation. I wrote a test program
to draw directly to the screen, or draw to an off GWorld then CopyBits. But
here is my question: if I "draw" by directly change the pixel values, what is
the difference between using offGWorld and drawing directly to the screen?
CopyBits takes very little time, relatively. Is writing to GWorld as "dangerous"
as writing to the screen? (in fact, I open a window as current port, and take
it as "current" GWorld, writing to it is just like writing to a off GWorld.)

Also, although it's easy to create some fix pattern graphics by writing
to the memory, how can one plot, say, an icon (a man, a dog) by changing the
pixel values, and even do animation?



+++++++++++++++++++++++++++

From: [e-mail] (hui  dong)
Organization: University of Chicago Computing Organizations
Date: Sun, 13 Sep 1992 08:43:43 GMT

I am also very interested in creating fast animation. I wrote a test program
to draw directly to the screen, or draw to an off GWorld then CopyBits. But
here is my question: if I "draw" by directly change the pixel values, what is
the difference between using offGWorld and drawing directly to the screen?
CopyBits takes very little time, relatively. Is writing to GWorld as "dangerous"
as writing to the screen? (in fact, I open a window as current port, and take
it as "current" GWorld, writing to it is just like writing to a off GWorld.)

Also, although it's easy to create some fix pattern graphics by writing
to the memory, how can one plot, say, an icon (a man, a dog) by changing the
pixel values, and even do animation?



+++++++++++++++++++++++++++

From: [e-mail] (Ben Haller)
Date: 18 Sep 92 16:57:30 GMT
Organization: Stick Software

In article <[e-mail]>
  [e-mail] writes:
>I am also very interested in creating fast animation. I wrote a test program
>to draw directly to the screen, or draw to an off GWorld then CopyBits. But
>here is my question: if I "draw" by directly change the pixel values, what is
>the difference between using offGWorld and drawing directly to the screen?
>CopyBits takes very little time, relatively. Is writing to GWorld as
>"dangerous" as writing to the screen? (in fact, I open a window as current
>port, and take it as "current" GWorld, writing to it is just like writing
>to a off GWorld.)
  The key phrase here is "CopyBits takes very little time, relatively."  If
you don't mind the overhead of CopyBits, then yes, feel free to use an
offscreen GWorld, that's very nice.  But if you want "fast animation",
as you say, the overhead of CopyBits is unacceptable.
  I have no idea if writing to GWorlds is similar to drawing direct to
screen, what the relative danger level is, etc., since I have never
done it.  Sorry.

>Also, although it's easy to create some fix pattern graphics by writing
>to the memory, how can one plot, say, an icon (a man, a dog) by changing the
>pixel values, and even do animation?
  The principle is the same - just write different color values to the
different pixels, and you're done.
  In practice, it is (usually) easier to have an offscreen copy of the
image, and move that image to the screen by reading bytes (or preferably
longwords for speed) and writing them out to the proper place in screen
memory.
  In certain cases it is even better to just write the values using
a hard-coded routine that can only "stamp" the one image it has been
written to produce, thus saving the reads from memory for the image.
  To do animation, just display several images in quick succession, making
sure that you remove the traces of each previous image as you display each
next image...

- -Ben Haller ([e-mail])

---------------------------

End of C.S.M.P. Digest
**********************